Log4j Sicherheitslücken (CVE-2021-44228,CVE-2021-4104,CVE-2021-44832,CVE-2019-17571)

ich muss mich hier Herrn Hamann anschließen und ein Update auf eine aktuelle Version begrüßen. log4j in Version 1.2.x ist bereits seit August 2015 EOL und es gibt darin ebenfalls offene CVE-Meldungen wie der Homepage zu entnehmen ist.

Bezüglich eines Updates der Eigenentwicklungen halte ich einen angekündigter Bruch der bisherigen API in den Release Notes für vertretbar.

TRANSCONNECT nutzt eine Vielzahl externer Bibliotheken. Aktuell ist es aber so, dass keine einzige davon Log4j 2.x nutzt. Wir haben aber seit mehreren Jahren für TRANSCONNECT selbst ein Update auf Log4j 2 geplant, das allerdings bisher noch aufgeschoben. Solange das nämlich dazu führen würde, dass wir dann beide Versionen mit ausliefern und gemischt nutzen müssten, würden wir die Anzahl möglicher Angriffsvektoren damit potenziell erstmal nur erhöhen. Die bekannten Schwachstellen von Log4j 1.2.17 sind uns natürlich bewusst, allerdings betreffen diese TRANSCONNECT nicht, da sie nur für bestimmte Konfigurationen ausgenutzt werden können.

Prinzipiell versuchen wir aber schon soweit möglich, alle benutzten Komponenten immer auf dem aktuellsten Stand zu halten. Gleichzeitig prüfen wir auch täglich automatisiert alle genutzten Bibliotheken gegen mehrere CVE-Datenbanken, um Schwachstellen schnellstmöglich zu erkennen. Bei neu erkannten Problemen werden diese einzeln bewertet und münden dann ggf. kurzfristig in ein Update oder spezielle Fixes.

Unter den aktuellen Umständen sehen wir jetzt aber durchaus das Potenzial, dass viele Bibliotheken in naher Zukunft den Umstieg auf Log4j 2 vollziehen werden. Damit eröffnet sich dann für uns die Möglichkeit, die 1er Version komplett zu entfernen und damit auch für TRANSCONNECT selbst ein entsprechendes Update vorzunehmen. Da das wie oben beschrieben zu inkompatiblen Änderungen führen wird, werden wir das dann aller Voraussicht nach im Zuge eines neuen Major-Releases machen.

ich vermute Sie beziehen sich hier auf den Teil

„Eine ähnliche Schwachstelle ist auch für die nicht mehr im Support befindlichen Versionen 1.x gemeldet worden, hierbei scheint die Ausnutzung allerdings komplexer zu sein. Da die Versionen 1.x jedoch den End-of-life (EOL) Status erreicht haben, wird es zu diesen keine Sicherheitsupdates mehr geben.“

in der entsprechenden BSI-Veröffentlichung? Diese Meldung ist leider etwas irreführend, da hier suggeriert wird, dass so ein Problem wie CVE-2021-44228 auch Log4j 1.x betrifft. Das ist, wie im ursprünglichen Post bereits erwähnt, in dieser Form gar nicht möglich. Die angreifbare Lookup-Funktion wurde erst mit Log4j 2 eingeführt.

Allerdings gibt es bei Logj4 1.x eine zumindest entfernt ähnliche Schwachstelle: CVE-2021-4104. Ähnlich deshalb, da auch hier durch die ungesicherte Deserialisierung von Daten aus einer nicht vertrauenswürdigen Quelle theoretisch beliebiger Code ausgeführt werden kann. Davon abgesehen unterscheiden sich beide Probleme aber grundlegend.

Durch CVE-2021-44228 ist die Kompromittierung eines Systems durch das simple Einschleusen eines Textfragments in irgendeine beliebige Lognachricht möglich. Das ist im Prinzip fast völlig unabhängig von der Konfiguration des angegriffenen Systems und kann extrem einfach ausgenutzt werden. Einem Angreifer muss dabei noch nicht einmal bekannt sein, welches Softwareprodukt er konkret angreift. Hier sollte davon ausgegangen werden, dass absolut jedes System betroffen ist, das eine Log4j-Version 2.0b – 2.16 benutzt. Alle zwischenzeitlich empfohlenen Maßnahmen zur Abwehr von Angriffen – abgesehen von der Holzhammer-Methode durch das Entfernen einiger Klassen aus der Bibliothek – haben sich mittlerweile als untauglich erwiesen.

Demgegenüber setzt CVE-2021-4104 eine ganz bestimmte und ziemlich ungewöhnliche Konfiguration voraus: Der JMSAppender muss benutzt werden und für JNDI-Lookups auf ein externes System konfiguriert sein. Es gibt hier grundsätzlich zwei Szenarien:

1. Ein Angreifer hat Zugriff auf die Log4j-Konfiguration, kann diese entsprechend manipulieren und damit Abfragen auf einen eigenen Server umleiten.
2. Log4j wurde von vornherein entsprechend konfiguriert. Dann wäre das System durch jeden angreifbar, der die Kontrolle über den konfigurierten Host hat.

Beide Varianten setzen also voraus, dass eines der beiden beteiligten Systeme bereits kompromittiert ist. Da im 1. Szenario ein Angreifer bereits Zugriff auf das Dateisystem des Systems haben muss, wäre das wohl auch maximal noch (unter weiteren Randbedingungen) zur Rechteausweitung eines unprivilegierten Nutzers einsetzbar. Hat ein Angreifer bereits umfassende Rechte, ist die Ausnutzung der Log4j-Schwachstelle nicht mehr nötig.

TRANSCONNECT ist von dieser Schwachstelle nicht betroffen, da die Log4j-Konfiguration programmatisch erfolgt und die Nutzung des JMSAppenders dabei gar nicht vorgesehen und somit auch nicht konfigurierbar ist.

Log4j 1.x hat auch noch eine andere bekannte Schwachstelle, die potenziell die Ausführung beliebigen Codes erlaubt: CVE-2019-17571. Genau wie bei CVE-2021-4104 kann diese Schwachstelle aber nur ausgenutzt werden, wenn Log4j entsprechend konfiguriert ist – hier als Netzwerk-Logserver. Auch das ist bei TRANSCONNECT so nicht vorgesehen und auch nicht konfigurierbar.

Trotz allem sind wir uns natürlich der Brisanz des Themas bewusst, der Wunsch nach weiterer Absicherung ist völlig verständlich. Deshalb arbeiten wir gerade an einem Update, um die vulnerablen Komponenten sicherheitshalber komplett aus der Log4j-Lib zu entfernen.

Kurzfristig – bis zur Verfügbarkeit des entsprechenden Updates – könnten Sie auch manuell sämtliche log4j-1.2.17.jar-Dateien (z.B. in den Ordnern transconnect/shared/lib und transconnect/sample/mapping/Mapping Functions/lib) durch diese Version ersetzen, um den Server gegen alle Eventualitäten abzusichern.

Viele Grüße,
Holger Rehn