Das halbe Internet und die meisten Sicherheitsbehörden sind gerade (zurecht) in Aufruhr versetzt. Der Grund: Eine kritische Sicherheitslücke in einer weit verbreiteten Software-Bibliothek, die ohne großen Aufwand ausnutzbar ist und von der gerade viele nicht wissen, ob sie betroffen sind. Software-Anbieter sind fleißig dabei, Patches zu bauen und auszurollen. Aber was ist mit eigenentwickelter Software? Wir haben ein paar schnelle Checks und Präventivmaßnahmen zusammengetragen.

Was kann passieren

Die Sicherheitslücke ermöglicht Remote-Code-Execution und erfordert vom Angreifer nur, einen String zu übermitteln, der vom System unverändert geloggt wird. Das kann eine Chatnachricht in Minecraft, oder ein Gerätename bei Verbindung mit der iCloud sein. Das BSI spricht von einer extrem kritischen Bedrohungslage.

Die Java-Version prüfen

Als erstes sollte die Java-Version auf allen Umgebungen, also auch auf im Internet erreichbaren Test-Umgebungen, geprüft werden. Die Lücke nutzt ein eher exotisches Java-Feature, das bereits vor einiger Zeit standardmäßig deaktiviert wurde. Wenn eine aktuelle Java-Version eingesetzt wird, schließt das die Lücke zwar nicht vollständig, erschwert einem möglichen Angreifer aber das Ausführen von Schadcode (siehe Guide: How To Detect and Mitigate the Log4Shell Vulnerability).

java -version

Laut Oracle-Changelogs wurden die betreffenden Properties mit Java8u121 auf false gesetzt. Laut einem Artikel von Lunasec sollte allerdings mindestens die Version 6u211, 7u201, 8u191 oder 11.0.1 verwendet werden. Wobei Java 6 und 7 ganz unabhängig von dieser Lücke nicht mehr ohne guten Grund verwenden werden sollten.

Die Abhängigkeiten prüfen

Die log4j Versionen 2.0 <= x <= 2.14.1 sind potentiell verwundbar. Ab 2.15 ist die Lücke geschlossen. Wenn man unschlüssig ist, welche Logging-Bibliothek oder -Version im eigenen Projekt verwendet wird, lässt sich das mit Maven oder Gradle relativ einfach herausfinden:

mvn dependency:tree | grep log4j-core -B 5

gradle -q dependencyInsight --dependency log4j-core

Diese Befehle durchsuchen den gesamten Abhängigkeitsbaum nach dem verwundbaren Paket. Der Parameter -B 5 mit Maven-Beispiel sorgt dafür, dass einige Zeilen vor dem Treffer mit ausgegeben werden. Das erleichtert das Lokalisieren einer transitiven Abhängigkeit.

Sollte das Update auf eine neuere Version länger dauern oder gar nicht möglich sein, kann bei Versionen ab 2.10 der Parameter -Dlog4j2.formatMsgNoLookups=true beim Start der Anwendung angegeben werden, um für schnelle Abhilfe zu sorgen. Andernfalls muss manuell ein Class-File aus dem Package entfernt werden (siehe Apache Mailing Liste).

Wie wir damit umgehen

Wir prüfen weiterhin unsere Systeme, wenn neue Informationen zur Lücke bekannt werden. Das gilt auch für Eigenentwicklungen, die wir selbst im Einsatz haben. Wir arbeiten sowohl intern, als auch in Kundenprojekten viel mit Spring Boot, welches standardmäßig auf logback anstatt log4j setzt und deshalb in den meisten Fällen nicht betroffen ist. Die bei Bedarf genutzte log4j-Version in Spring soll noch vor Weihnachten aktualisiert werden (siehe Spring Blog).

Log4Shell Logo von GossiTheDog

Aktualisiert um 15:30: Gradle-Beispiel und Verweis zum BSI hinzugefügt.

Aktualisiert um 16:00: Text angepasst: Ein Java-Update schließt die Lücke nicht vollständig.