GitHubs Antwort auf die kritische Log4j-Lücke

Inhaltsverzeichnis

Die seit dem 9. Dezember bekannte Sicherheitslücke in der Logging-Bibliothek Log4j hat auch bei GitHub das Sicherheitsteam alarmiert. Innerhalb kürzester Zeit hatte die Lücke es unter der Bezeichnung CVE-2021-44228 auf die Liste offizieller Schwachstellen Common Vulnerabilities and Exposures geschafft, da sie international als besonders kritisch eingestuft wird. Die verwundbare Bibliothek ist Open Source und insbesondere in Java-Anwendungen weitverbreitet, ein Ausnutzen der Lücke könnte demzufolge zahlreiche große und kleine Unternehmen, aber auch Privatleute weltweit betreffen.

GitHub gibt der Community Sicherheitshinweise

Das Sicherheitsteam von GitHub hat die eigene Infrastruktur und die Plattform auf eine mögliche Gefährdung durch Log4jShell-Angriffe untersucht und in einem Blogpost die aktuellen Erkenntnisse veröffentlicht. Zudem hat GitHub ein Security Advisory herausgegeben, mit Sicherheitshinweisen, wie die Community ihre Projekte auf ein Vorliegen der Schwachstelle prüfen kann.

Laut Sicherheitsteam ist die Log4j-Schwachstelle bei den GitHub-Enterprise-Servern in der empfohlenen Konfiguration nur für authentifizierte Nutzer zugänglich. Falls allerdings eine Instanz abweichend konfiguriert ist und den Private Mode ausschließt, könnte die Schwachstelle auch nicht authentifizierten Nutzern offenstehen. Die eigenen Instanzen auf den Enterprise-Servern lassen sich wie folgt absichern:

1. Gepatchte Version: Durch das Aktualisieren auf eine neue Version der GitHub Enterprise Server, die bereits Änderungen zum Beheben der Schwachstelle enthält, lassen sich eigene Instanzen absichern. Infrage kommen dafür die Versionen 3.3.1, 3.2.6, 3.1.14 und 3.0.22.
2. Hotpatch: Das Aktualisieren einer vorhandenen Instanz mit einem Hotpatch ist ebenfalls eine Option und soll ohne Wartungsfenster möglich sein. Wer diesen Weg wählt, sollte die Hotpatch-Anweisungen von GitHub befolgen.

Das GitHub-Team hat dem Blogeintrag zufolge ab dem 10. Dezember Maßnahmen ergriffen, um die möglichen Auswirkungen auf GitHub.com und die GitHub Enterprise Cloud gering zu halten. Konkret wurden die Telemetriedaten überprüft und zusätzliche Überwachung eingeleitet, wobei laut Team noch kein erfolgreicher Angriff auf die Log4j-Schwachstelle erkennbar war. Das Unternehmen führt die Untersuchung und das Monitoring weiterhin durch und stellt perspektivisch weitere Updates bereit, sofern weitere Angriffspunkte bekannt werden.

Was jetzt zu tun ist und wie Maintainer Instanzen absichern

Potenziell betroffen ist der gesamte Versionszweig 2.x vor der gepatchten neuen Version 2.16. Ältere Log4j-Versionen, die noch zum 1.x-Zweig gehören (der nicht länger mit Updates versorgt wird, End of Life) ist zwar offenbar von der aktuellen Lücke nicht betroffen, dafür hingegen für andere Schwachstellen bekannt, sodass GitHub Maintainern in jedem Fall ein zügiges Update auf die neue Version 2.16 empfiehlt.

Wer seine Infrastruktur auf die Log4j-Lücke überprüfen möchte, kann sich dabei auch von Tools unterstützen lassen. Eine Möglichkeit wäre beispielsweise der Log4JShell Bytecode Detector, der auf GitHub im CodeShield-Repository liegt. Da ein Scan auf die Bibliothek nicht trivial ist, können derartige Tools allerdings nur unterstützen. Sie liefern in der Regel keine hundertprozentige Erkennung in allen Situationen.

Auf dem Laufenden bleiben

GitHub hält in seinem Security-Blog alle Interessierten auf dem Laufenden. Die hier besprochene Mitteilung zum Stand der Dinge an der Log4j-Front lässt sich im aktuellen Blogeintrag nachlesen. Weitere Hinweise und Updates finden sich auf der Webseite des Log4j-Projekts bei Apache. Das Log4j-Team hat dort auch einen Migrationsleitfaden veröffentlicht, der beim Umstieg auf eine gepatchte Version der betroffenen Library helfen soll.

[Update 15.12.2021 6:52 Uhr] Auch Log4j 2.15 gilt als fehleranfällig. Erst ab Log4j 2.16 ist man auf der sicheren Seite, wie wir dank eines Leserhinweises erfahren haben.

(sih)