Vor einigen Tagen habe ich über „Log4Shell“ berichtet, eine schwere Sicherheitslücke in der Bibliothek Log4j. Als Reaktion darauf wurde Log4j in Version 2.15 veröffentlicht. Seit kurzem gibt es jedoch eine weitere Version 2.16: Sie soll neue Fehler korrigieren, die inzwischen bekannt geworden sind. In diesem Beitrag schauen wir uns an, welche dies sind und wir ihr darauf reagieren solltet.
Mithilfe der CVE-Nummern können wir die Lücken zuordnen und Klarheit schaffen. Zur Erinnerung: CVE-2021-44228 war die als Log4Shell bekannte schwere Sicherheitslücke, bei der per JDNI beliebig Schadcode auf dem System ausgeführt werden konnte. CVE-2021-44228 wurde in Log4j Version 2.15 behoben.
CVE-2021-45046: Die erste neue Lücke
Unter der Nummer CVE-2021-45046 wurde eine zweite Schwachstelle bekannt: Sie verwendet ebenfalls JNDI-Aufrufe, allerdings für DoS-Angriffe. DoS steht für Denial of Service und bedeutet, dass man das Zielsystem lahm legt. Etwa mit vielen Anfragen, wodurch es zur Überlastung kommt. Für Nutzer steht der Dienst dann nicht zur Verfügung. Auf einem Minecraft-Server kann keiner Spielen, eine Internetseite ist nicht erreichbar und so weiter.
Im Gegensatz zu CVE-2021-44228 von Log4Shell kann CVE-2021-45046 nicht dafür missbraucht werden, um beliebig Schadcode auf dem Zielsystem auszuführen. Diese neue Lücke ist daher sicherheitstechnisch deutlich weniger kritisch, wenngleich Updates natürlich auch hier zu empfehlen sind. Sie betrifft alle Versionen bis einschließlich 2.15, nur 2.16 ist nicht betroffen.
Der Hintergrund ist: In Log4j 2.15 wurde JDNI auf lokale Adressen (localhost) limitiert, um die unkontrollierte Ausführung von Code zu verhindern. Aktiv ist JDNI damit aber weiterhin. In Version 2.16 hat man sich dazu entschieden, JDNI komplett zu deaktivieren – sicherheitstechnisch in meinen Augen eine sinnvolle Entscheidung.
Wichtig: Der im vorherigen Beitrag empfohlene Workaround log4j2.noFormatMsgLookup=True hilft nur gegen die alte Log4Shell Sicherheitslücke (CVE-2021-44228). Gegen die neue DoS-Lücke CVE-2021-45046 bietet er keinen Schutz! Hier hilft nur zu aktualisieren. Oder wenn dies nicht möglich ist, weil es sich um (proprietäre) Drittanbieter-Software handelt: Auf den Hersteller der Software zu warten bzw. bei der entsprechenden Stelle Druck zu machen, damit ein Update bereitgestellt wird.
CVE-2021-4104: Eine neue Sicherheitslücke in log4j 1.2
Die zweite Lücke ist dagegen sicherheitskritischer: Sie erlaubt das Ausführen von Code aus der Ferne, ähnlich gefährlich wie Log4Shell. Allerdings betrifft sie nur Log4j 1.2. Diese Version ist seit 2015 durch Version 2 abgelöst worden, erhält also keine Aktualisierungen mehr. Leider haben sich nicht alle Entwickler/Hersteller um die Pflege ihrer Abhängigkeiten gekümmert, sodass auch heute noch die alte 1.x Versionen eingesetzt werden.
Im Gegensatz zu Log4Shell kann CVE-2021-4104 aber nur ausgenutzt werden, wenn der JMSAppender aktiviert ist. Zwar lassen sich auch hier JDNI-Anfragen missbrauchen. Doch JMSAppender ist standardmäßig nicht aktiv. Dadurch sind weit weniger betroffen, als bei Log4Shell.
Fazit: Mehr Arbeit wegen fehlendem Sicherheitsbewusstsein
Die zwei neuen Lücken sind vom Schadpotenzial her beide deutlich weniger gravierend, als Log4Shell. Dennoch macht es Sinn, möglichst auf die neueste Version 2.16 zu aktualisieren. Zwar kann ein DoS-Angriff einen Server nicht kompromittieren. Dennoch ist es ärgerlich, wenn durch Ausnutzung dieser Lücke Dienste nicht erreichbar sind.
Dass CVE-2021-4104 in Log4j auch 6 Jahre nach dem Wechsel auf Version 2 teils immer noch ein Thema ist, unterstreicht die Problematik, welche ich im vorherigen Beitrag gegen Ende angesprochen habe: Viele ziehen sich Abhängigkeiten nicht nur ungeprüft in ihre Projekte, sondern kümmern sich zudem nicht ausreichend um deren Pflege.
Wenn in dieser Hinsicht bei den Entwicklern und vor allem Unternehmen kein Umdenken stattfindet, wird Log4Shell nicht die einzige Sicherheitslücke bleiben, die einen Großteil des Internets bedroht – bis hin zu Top-Unternehmen wie Amazon oder Apple, wo jeder iPhone-Benutzer durch das Einfügen einer Zeichenkette im Name seines iPhones theoretisch Vollzugriff auf Apples Systeme erhalten konnte. Selbstverständlich ist das nur ein Beispiel von vielen. Es sind nicht nur zahlreiche weitere Unternehmen betroffen, sondern auch Geheimdienste wie die NSA. Und zwar jene, die Massenüberwachung nahezu weltweit betreiben und kein Problem damit haben, Sicherheitslücken auf dem Schwarzmarkt zur eigenen Ausnutzung zu kaufen.