View Full Version : log4j Sicherheitslücke
holgerscherer
13-12-21, 17:19
aktuelle zentrale Infostelle hier
https://www.ibm.com/blogs/psirt/
holgerscherer
13-12-21, 20:10
aktuelle zentrale Infostelle hier
https://www.ibm.com/blogs/psirt/
schnelle Quick-and-dirty Abhilfe, um das Auswerten von Ausdrücken zu unterbinden:
UPDATE: das war zu quick - Befehl angepasst. Bitte mit WRKLNK kontrollieren.
QSH CMD('echo "log4j2.formatMsgNoLookups=true" >> /QIBM/UserData/Java400/SystemDefault.properties')
RobertMack
14-12-21, 08:56
Jesse Gorzinski (Entwickler ACS) empfiehlt als vorbeugende Maßnahme:
ADDENVVAR ENVVAR(LOG4J_FORMAT_MSG_NO_LOOKUPS) VALUE('true') REPLACE(*YES) LEVEL(*SYS)
Frage an die Kollegen mit 'nem schwarzen Gürtel in Java: gibt es für frühere Versionen (V6, V5) weitere/andere Umgebungsvariablen die man berücksichtigen sollte?
... die OS400 und Java Versionen spielen hier keine Rolle. Es geht bei der Sicherheitslücke darum, dass Strings, die über log4j protokolliert werden, vor der Ausgabe interpretiert werden, was man mit obiger Einstellung abstellen kann. System, auf denen keine log4j Logdateien erstellt werden (das dürfte für die meisten AS/400 Installationen zutreffen) sind ohnehin nicht betroffen.
D*B
Wenn log4j-Logdateien gespeichert werden, in welchem Pfad sollten sich diese Dateien befinden?
LG Michi
Andreas_Prouza
14-12-21, 15:45
Das wird in einem Property (log4j.properties) oder XML File (log4j.xml) hinterlegt.
Diese ist normalerweise in einem etc oder cfg Ordner der jeweiligen Java Applikation.
... am sinnigsten fängt man damit an nach log4j*.jar zu suchen. Wenn da nix ist => Entwarnung.
Die Protokolle sind schon schlechter zu finden, da die Namen konfiguriert werden und es könnte auch auf Konsole ausgegeben werden, was aber unüblich ist. Das weitere findet man eigentlich nur in den Java Applikationen, da muss man untersuchen, was die da so ausgeben könnten.
Am Beispiel von ArdGate:
- ArdGate protokolliert die SQL Statements, die prepared werden.
- wenn man da von außen beliebiges reingeben kann, dann könnte das für Angriffe genutzt werden. Das wäre auch ohne den Bug schon ein Risiko, drop table ist auch so meist nicht erwünscht. Wenn man für den Vergleich in einer where Klausel was frei eingeben darf, dann ist das für manche Datenbanksysteme schon wieder eine Möglichkeit einen drop table rein zu tricksen - könnte aber auch für einen log4shell Angriff genutzt werden. Hat man hier sauber programmiert, stellt ArdGate kein Risiko dar.
Das tückische ist, dass das schließen der Lücke durch einen patch (ADDENVVAR oder SystemDefault.properties oder update von log4jxxx.jar) das Problem nicht sicher heilt, weil jemand in der Vergangenheit sich unbemerkt eine Hintertür installiert haben könnte, die zu beliebigem Zeitpunkt für Schadangriffe genutzt werden könnte.
D*B
Allerdings lassen sich Jar's wiederum in eine eigene Jar einbetten.
Bei Eclipse gibts eine Einstellung "Package required libraries into the generated JAR".
holgerscherer
14-12-21, 22:15
kleines Update - wer es im Einsatz hat, sollte 2.16.0 verwenden, besonders, wenn viele Zugriffe von $(aussen) erwartbar sind.
Nach meinen Logfiles ist Russland grade führend :)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
Allerdings lassen sich Jar's wiederum in eine eigene Jar einbetten.
Bei Eclipse gibts eine Einstellung "Package required libraries into the generated JAR".
... das wird (fast) ausschließlich im Deployment eingesetzt und bei der automatischen Installation wieder aufgelöst. Bei korrekter Vorgehensweise sollen libraries, wie log4j für separate updates verfügbar sein.
D*B