Die Apache-Entwickler haben nach der vergangenen Freitag hastig veröffentlichten Version 2.15.0 zum Schließen der Log4Shell-Sicherheitslücke jetzt Log4j 2.16.0 fertig gestellt und darin die Schutzmaßnahmen verbessert. Auf der anderen Seite haben Sicherheitsforscher Proof-of-Concept-Code (PoC) zum Ausnutzen der Schwachstelle verfeinert – Angriffe funktionieren damit unabhängig von der Java-Version und bestimmten Java-Sicherheitseinstellungen. Verlässlichen Schutz bietet daher nur ein Update der Log4j-Bibliothek.
In Log4j 2.16.0 haben die Apache-Programmierer den Code entfernt, der Nachrichten in den Logs mit den fatalen URL-Einträgen zu potenziell bösartigen LDAP-Servern analysiert. Dazu deaktivieren die Entwickler das Java Naming and Directory Interface (JNDI) nun gänzlich. Nutzer könnten ihn manuell wieder einschalten, er stelle allerdings in ungeschützter Umgebung ein hohes Sicherheitsrisiko dar, warnen die
Der Sicherheitsforscher Márcio Almeida hat ein Exploit-Kit zum Ausnutzen der Log4Shell-Schwachstelle angepasst, sodass es mit jeder Java-Version funktioniere und auch etwa die Einstellung trustURLCodebase=false nicht dagegen helfe. Dazu hat er die bösartigen Daten, den Schadcode, einfach in ein anderes Format umgepackt (Serialization). Einzige Bedingung sei, dass die vom eingeschleusten serialisierten Code genutzten Klassen im Klassenpfad der angegriffenen Anwendung liegen müssten.
Almeida verweist darauf, dass ausschließlich das Update von Log4j – und zwar so schnell wie möglich – gegen das Ausnutzen der Sicherheitslücke Log4Shell helfe. Da bietet es sich an, gleich auf die neue, noch besser gesicherte Version Log4j 2.16.0 zu aktualisieren. Allerdings liegen bislang noch keine gesicherten Erkenntnisse zu möglichen Nebenwirkungen des Updates vor.
"Was genau sollte ich jetzt tun?" ist die zentrale Frage des heise-Security-Webinars "
Quelle: heise
In Log4j 2.16.0 haben die Apache-Programmierer den Code entfernt, der Nachrichten in den Logs mit den fatalen URL-Einträgen zu potenziell bösartigen LDAP-Servern analysiert. Dazu deaktivieren die Entwickler das Java Naming and Directory Interface (JNDI) nun gänzlich. Nutzer könnten ihn manuell wieder einschalten, er stelle allerdings in ungeschützter Umgebung ein hohes Sicherheitsrisiko dar, warnen die
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
.Java-Versions-Roulette
Zunächst fand sich am vergangenen Freitag in der ersten Fassung der Apache-Sicherheitsmeldung zur Lücke ein Hinweis auf eine bestimmte Java-Version, die Angriffe verhindere. Der Hinweis wurde kurz darauf entfernt. Es hat sich inzwischen herausgestellt, dass keine Java-Version verlässlich vor einem Angriff schützen kann.Der Sicherheitsforscher Márcio Almeida hat ein Exploit-Kit zum Ausnutzen der Log4Shell-Schwachstelle angepasst, sodass es mit jeder Java-Version funktioniere und auch etwa die Einstellung trustURLCodebase=false nicht dagegen helfe. Dazu hat er die bösartigen Daten, den Schadcode, einfach in ein anderes Format umgepackt (Serialization). Einzige Bedingung sei, dass die vom eingeschleusten serialisierten Code genutzten Klassen im Klassenpfad der angegriffenen Anwendung liegen müssten.
Almeida verweist darauf, dass ausschließlich das Update von Log4j – und zwar so schnell wie möglich – gegen das Ausnutzen der Sicherheitslücke Log4Shell helfe. Da bietet es sich an, gleich auf die neue, noch besser gesicherte Version Log4j 2.16.0 zu aktualisieren. Allerdings liegen bislang noch keine gesicherten Erkenntnisse zu möglichen Nebenwirkungen des Updates vor.
"Was genau sollte ich jetzt tun?" ist die zentrale Frage des heise-Security-Webinars "
Du musst dich
Anmelden
oder
Registrieren
um diesen link zusehen!
" am Montag, den 20. Dezember um 11:00.Quelle: heise
