nicht angemeldet
Rolf B
Rolf B
Rolf B
Rolf B
Hallo alle,
Diese Meldung ist für PHP-Websites irrelevant, aber sicherlich hat hier auch jemand einen Kater am Werk (Tomcat) oder andere aus dem Netz erreichbare Java-Services.
Die bezeichnete Schwachstelle in der Log4J Library ermöglicht dem Angreifer, den Server komplett zu übernehmen.
Eine nicht zu alte Version der verwendeten JRE verringert die Angriffsfläche, und ein Update auf Log4J 2.15 behebt das Problem, heißt es. Der im BSI Report verlinkte Artikel bei lunasec.io zeigt mögliche Interimsmaßnahmen auf.
Rolf
Hallo alle,
Diese Meldung ist für PHP-Websites irrelevant, aber sicherlich hat hier auch jemand einen Kater am Werk (Tomcat) oder andere aus dem Netz erreichbare Java-Services.
Oder, für mich wichtig, VM-Ware… und ansonsten UniFi.
Seite 2
Hi,
wonach müsste ich denn gucken auf unseren Systemen, ob das Gelumpe überhaupt installiert ist?
Wir haben Windows-Server, Windows 10 Desktops, Linux-Server und -Desktops im Einsatz. Das sind zusammen zwar nur ein paar Dutzend Systeme, aber man weiß ja nie.
Müssen die Systemd denn für den Angriff direkt mif einem Bein (offenem Port) im Internet hängen, oder reichen da schon Kommunikationen von innen nach außen mit infizierten Systemen?
Sind ggf. auch Router betroffen?
LG
Ralf
Hallo Ralf,
log4j ist eine Lib, die von Java Programmen für's Logging genutzt wird. Normalerweise findet mal ein log4j*.jar im Installationsordner dieser Application. Je nach Umfeld muss das natürlich nicht unbedingt bedeuten, dass sie auch verwendet wird.
Betroffen sind die Versionen 2.0 bis 2.14, die Version findet sich im Namen des JAR.
Kritisch ist die Sache bei Systemen, die Daten von irgendwo außerhalb empfangen und diese in ein Logfile schreiben könnten. Denn dann könnte in den geloggten Daten eine spezielle ${...} Zeichenfolge sein, die einen JNDI-Lookup auslöst - und darüber lässt sich Unsinn anrichten. Begriffen habe ich das selbst auch nicht. Ich bin kein Java-Entwickler, ich bin im Beruf nur Produktverantwortlich für mehrere zugekaufte Java-Anwendungen. Bei einer von denen konnte ich die JAR einfach durch die 2.15 Version austauschen und die App lief sauber weiter, aber das ist nicht garantierbar.
Du müsstest also die Java Anwendungen oder -Services katalogisieren, die ihr verwendet, und bei denen gucken, was sie tun. Ein Filesystem-Scan nach log4j*.jar kann helfen.
Ich kann Dir keinen detaillierten Rat geben. Ich weiß auch nur, was auf den BSI-Seiten und ein paar davon verlinkten Seiten steht.
Ob Router betroffen sein könnten? Keine Ahnung, ob ein Router mit log4j irgendwas loggen möchte.
Rolf
Hello Rolf,
Du müsstest also die Java Anwendungen oder -Services katalogisieren, die ihr verwendet, und bei denen gucken, was sie tun. Ein Filesystem-Scan nach log4j*.jar kann helfen.
Interessanter Ansatz, um überhaupt erstmal die Gefahr für die Systeme einzuschätzen.
Ich habe auf unseren Linux-Servern im Hotel und meinem Desktop gesucht:
TS
MudGuard
Der Martin
Augesudo find / -name log4j
Wäre das so ausreichend?
Glück Auf
Tom vom Berg
Hallo TS,
keine Ahnung. Ich weiß nicht, wie der find-Befehl arbeitet. Die Dateien beginnen mit log4j, dahinter kommt ein Namensteil (-API, -CORE, viele mehr) und eine Versionsangabe, und dann ".jar".
Ich kann euch nicht beraten. Lest selbst, schätzt selbst ein. Ihr managed eure Systeme.
Rolf
Hello,
Ich habe auf unseren Linix-Servern im Hotel und meinem Desktop gesucht:
sudo find / -name log4jWäre das so ausreichend?
was macht denn der log4j-detector wohl?
Wenn keine JAR-Runtimes installiert sind, dürfte der doch nichts finden, oder?
Was ist dann mit den ganzen Desktopsystemen mit Eclypse usw? Die verwenden doch Java, oder?
Glück Auf
Tom vom Berg
Ich habe auf unseren Linix-Servern im Hotel und meinem Desktop gesucht:
sudo find / -name log4jWäre das so ausreichend?
was macht denn der log4j-detector wohl?
Augenscheinlich deutlich mehr als ein "find".
Hi,
was macht denn der log4j-detector wohl?
Wenn keine JAR-Runtimes installiert sind, dürfte der doch nichts finden, oder?
java-Archive (jar oder war oder ...) können im Inneren weitere Archive enthalten - die müssen also auch (rekursiv) durchsucht werden.
cu,
Andreas a/k/a MudGuard
Hello,
Ich habe auf unseren Linix-Servern im Hotel und meinem Desktop gesucht:
sudo find / -name log4jWäre das so ausreichend?
was macht denn der log4j-detector wohl?
Wenn keine JAR-Runtimes installiert sind, dürfte der doch nichts finden, oder?
Was ist dann mit den ganzen Desktopsystemen mit Eclypse usw? Die verwenden doch Java, oder?
Auf einem Linux-System liefert:
sudo dpkg --get-selections *java* | less
die Module
ca-certificates-java install
gir1.2-javascriptcoregtk-4.0:amd64 install
java-common install
libel-api-java install
libhsqldb1.8.0-java install
libjavascriptcoregtk-4.0-18:amd64 install
libjsp-api-java install
libjuh-java install
libjurt-java install
libreoffice-java-common install
libridl-java install
libservlet-api-java install
libservlet3.1-java install
libunoil-java install
libunoloader-java install
libwebsocket-api-java install
Wie stelle ich da jetzt fest, wer die alles braucht (also die Abhängigkeiten) und ob ich das Geraffel entfernen kann?
Glück Auf
Tom vom Berg
Auf einem Linux-System liefert:
sudo dpkg --get-selections *java* | less
Solange Du Dir sicher bist, ausschließlich aus Paketquellen Kram auf Deinem System zu haben: schön. Trotzdem weiste nicht, ob da irgendwo ein vulnerables Log4j verbuddelt ist. Als allgemeingültige Analyse ist das daher komplett untauglich.
Im Übrigen „liefert“ das nicht auf einem Linux-System, sondern auf Deinem. Auf anderen mag „dpkg“ mit einem „command not found“ antworten.
Wie stelle ich da jetzt fest, wer die alles braucht
Einer von vielen Wegen wäre:
apt show "*" | grep -P "Package:|Depends:" | grep ".*java.*" | less
und ob ich das Geraffel entfernen kann?
Naja, ganz stumpf und einfach:
sudo apt --purge autoremove
Löscht alle Pakete (und, wegen --purge deren Konfiguration), wenn keine Abhängigkeit mehr besteht. Also auch die, nach denen Du fragst. Und veraltete Kernel.
Aber, wie der Mitleser schon feststellt, betrifft das nur Debian-artige Linuxe und funktioniert genau dann nicht, wenn das Zeug als Teil diese hässlichen Snaps oder proprietären Programmen (s. VMWare) und somit eben anders als mit apt oder dpkg auf den Rechner gekommen ist.
Auf anderen Linuxen gibt es aber auch ähnliche Programme, die im Prinzip den gleichen Job machen.
Hello,
Wie stelle ich da jetzt fest, wer die alles braucht
Einer von vielen Wegen wäre:
apt show "*" | grep -P "Package:|Depends:" | grep ".*java.*" | lessund ob ich das Geraffel entfernen kann?
Naja, ganz stumpf und einfach:
sudo apt --purge autoremove
OB und nicht wie ;-)
Wird da wohl durchaus Überraschungen geben können, welche Programme davon alles betroffen sind.
Löscht alle Pakete (und, wegen
--purgederen Konfiguration), wenn keine Abhängigkeit mehr besteht. Also auch die, nach denen Du fragst. Und veraltete Kernel.Aber, wie der Mitleser schon feststellt, betrifft das nur Debian-artige Linuxe und funktioniert genau dann nicht, wenn das Zeug als Teil diese hässlichen Snaps oder proprietären Programmen (s. VMWare) und somit eben anders als mit
aptoderdpkgauf den Rechner gekommen ist.Auf anderen Linuxen gibt es aber auch ähnliche Programme, die im Prinzip den gleichen Job machen.
Das war ja auch exemplarisch gemeint. Der Mitesser wollte doch nur seinen Eiter dazu geben, äh ich meinte, der Mitleser wollte uns nur erheitern.
Glück Auf
Tom vom Berg
Hallo,
und ob ich das Geraffel entfernen kann?
Naja, ganz stumpf und einfach:
sudo apt --purge autoremoveOB und nicht wie ;-)
das ob kannst du vorab bestimmen, wenn du den Schalter -s zusätzlich angibst. Dann simuliert apt-get die Aktion nur, und du siehst, was passieren würde.
Andererseits ist autoremove im Normalfall ungefährlich, weil der Paketmanager so nur die Pakete entfernt, die von keinem anderen Paket mehr benötigt werden. Das ist zumindest so lange sicher, wie die Paket-Datenbank nicht korrumpiert ist.
Wird da wohl durchaus Überraschungen geben können, welche Programme davon alles betroffen sind.
Normalerweise nicht. Das ist ja der Sinn des Paketmanagers, dass er über Abhängigkeiten Buch führt.
Aber, wie der Mitleser schon feststellt, betrifft das nur Debian-artige Linuxe
Ja, natürlich. Andere Paketmanager haben aber ähnliche Funktionen.
und funktioniert genau dann nicht, wenn das Zeug als Teil diese hässlichen Snaps oder proprietären Programmen (s. VMWare) und somit eben anders als mit
aptoderdpkgauf den Rechner gekommen ist.
Richtig. Dann weiß der Paketmanager nichts davon und kann das Paket auch nicht entfernen. Dadurch geht zumindest nichts kaputt, aber das potentiell schädliche Programm wird auch nicht entfernt.
Immer eine Handbreit Wasser unterm Kiel
Martin
Hallo,
und ob ich das Geraffel entfernen kann?
Naja, ganz stumpf und einfach:
sudo apt --purge autoremoveOB und nicht wie ;-)
das ob kannst du vorab bestimmen, wenn du den Schalter -s zusätzlich angibst. Dann simuliert apt-get die Aktion nur, und du siehst, was passieren würde.
Es wird, solange man nicht die Option --force oder -f ohnehin gefragt…
B.T.W. Da ja beharrlich so beharrlich wie bedauerlich geschwiegen wurde:
Den Hinweis, dass durch die Angabe von --purge die Konfiguration gelöscht wird, habe ich gegeben - und wir sind hier nicht im Kindergarten. (Wer es doch denkt, sollte sowieso über seine eigene Konfiguration nochmals nachdenken, bei einem erneuten Setup muss er dann) Ebenso habe ich darauf verweisen, dass andere Distributionen andere Mechanismen verwenden. Ansonsten kann ich nichts entdecken, was an meiner Antwort auch nur problematisch sein könnte.
Sollte sich jedoch eine Missfallens-Bekundung gegen meine negative Bewertung von Snaps richten: Dafür habe ich viele gute Gründe:
Hier drei davon:
Hi,
Den Hinweis, dass durch die Angabe von
--purgedie Konfiguration gelöscht wird, habe ich gegeben
ja, hast du. Das ist ja der Sinn dieses Schalters. Warum betonst du das so?
und wir sind hier nicht im Kindergarten.
Hat das jemand behauptet? Bist du heute mit dem falschen Fuß zuerst aufgestanden?
(Wer es doch denkt, sollte sowieso über seine eigene Konfiguration nochmals nachdenken, bei einem erneuten Setup muss er dann) Ebenso habe ich darauf verweisen, dass andere Distributionen andere Mechanismen verwenden. Ansonsten kann ich nichts entdecken, was an meiner Antwort auch nur problematisch sein könnte.
Ich auch nicht. Wie kommst du drauf, dass jemand anders das unterstellt?
Sollte sich jedoch eine Missfallens-Bekundung gegen meine negative Bewertung von Snaps richten: Dafür habe ich viele gute Gründe:
Die Abneigung teile ich, und aus sehr ähnlichen Gründen.
Immer eine Handbreit Wasser unterm Kiel
Martin
Hallo
…
… Warum betonst du das so?
…
Hat das jemand behauptet? Bist du heute mit dem falschen Fuß zuerst aufgestanden?
… Wie kommst du drauf, dass jemand anders das unterstellt?
Sein Beitrag, auf den sich das bezieht, hat – unter anderem – eine negative Bewertung erhalten. Frag mich nicht nach dem Grund dafür, ich sehe keinen.
Tschö, Auge
Hallo TS,
(h)Eiter
Bitte hört auf mit diesen Spitzen. Beide. Ich habe keine Lust, im Moderationsmeldungs-Pingpong den Spielball zu geben und im 10-Minuten-Takt eine "Bääää, der ist hat mir aber unkonstruktiv ans Beinchen gestrullert" Meldung wegklicken zu müssen.
Rolf
https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html
Das klärt dann auch gleich, warum ich bestimmte, „moderne“ Programmiertechniken Vorgehensweisen bei der Erstellung von Programmen nicht mag.
Hallo Heise.de,
vielen Dank für diesen herrlichen Artikel.
Mehr Entwicklungsgeschwindigkeit macht größere Krater.
Das hat mich dann unter den Tisch gerollt. Vor Lachen. Unter dem Tisch hab ich mich dann zusammengerollt und geflennt…
Rolf
Aber Firmen stellen seit etwa einer Dekade Leute ein, die nicht wissen, was stdout und stderr sind und das ist irgendwie okay, weil inzwischen ja sowieso alles ein Webservice ist.
Da lag ich unter dem Tisch. Auch erst mal lachend - und dann weinend.
Denn wie ich Dinge sehe werden da wild Programme mit bootstrap zusammengekehrt und dann braucht man natürlich Stundenlang um mit Unit-Tests um herauszubekommen, was so ein 20-Zeiler macht.
Und wehe, (Wehe!) jemand kommt und sagt, das hätte man mit 30 Zeilen offensichtlich zwingend richtig funktionierend schreiben können…
Update
Bitte informiert euch - ich kann das hier nicht alles erklären. Das meiste kapiere ich eh selber nicht 😂
Rolf
Hallo,
und damit wir nicht arbeitslos werden, hat man in der Log4J Version 2.16 noch eine potenzielle DoS Attackemöglichkeit identifiziert, die bei "geschickt" gewählten Patterns zu einer Endlosrekursion führen kann und damit Software abstürzen lässt.
Es gibt nun eine Version 2.17
Rolf