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

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