Neun Monate ungepatchte Schwachstelle gefährdet Java-Anwendungen

Sicherheitsmanagement
Java (Bild: Oracle)

Die Lücke kann zum Einschleusen und Ausführen von Schadcode missbraucht werden. Sie findet sich in einer unsicheren Methode, mit der Java Objekte deserialisiert. Anwendungen wie JBoss, Jenkins, OpenNMS, WebSphere oder WebLogic sind davon betroffen. Erste Projekte haben schon Patches angekündigt.

Foxglove Security hat auf eine Schwachstelle in der häufig eingesetzten Apache-Commons-Bibliothek hingewiesen. Sie lässt sich ausnutzen, um Schadcode einzuschleusen und auszuführen. Sie ist auf eine unsicher umgesetzte Methode zurückzuführen, mit deren Hilfe Java-Objekte deserialisiert werden. Gefahr besteht bedroht Java-basierende Applikationen wie JBoss, Jenkins, OpenNMS, WebSphere oder WebLogic.

Java (Bild: Oracle)

Die Schwachstelle ist den Sicherheitsexperten zufolge bereits seit mehr als neun Monaten bekannt. Da Java-Anwendungen abhängige Bibliotheken mit jeder Applikation bündeln, statt Shared Libraries zu verwenden, dürfte die Lücke bereits seit geraumer Zeit ausgenutzt werden.

“Jeder Anwendungsserver kommt mit einem eigenen Paket von Bibliotheken. Noch schlimmer: jede Anwendung, die auf dem Server installiert wird, bringt oft ebenfalls ihre eigene Sammlung mit”, schreibt Sicherheitsforscher Steve Breen. “Um dies komplett zu beheben, muss man jede einzelne Bibliothek identifizieren und aktualisieren.”

Breen hat auch einen Exploit für die Schwachstelle entwickelt. Ihm zufolge basiert er auf einer ähnlichen Lücke in Apache Commons, die ebenfalls mit der Deserialisierung von Objekten zusammenhängt. Diese Schwachstelle ist schon seit Januar öffentlich bekannt.

Breen konnte nach eigenen Angaben angepasste Payloads erstellen, um sich Shell-Zugriff zu verschaffen. Das funktioniere auf Maschinen, auf denen JBoss, Jenkins, OpenNMS, WebLogic oder WebSphere laufen oder die Java Remote Method Invocation nutzen.

Apache und Jenkins haben mittlerweile reagiert, und Patches angekündigt, um die Lücke zu schließen. Jenkins veröffentlichte einen Workaround, der das für den Angriff ausgenutzte Jenkins CLI System deaktiviert. Ein Patch soll am kommenden Mittwoch erhältlich sein. “Unglücklicherweise wurden wir vor der Veröffentlichung nicht über die Lücke informiert, sodass wir noch an einem Fix arbeiten”, teilte das Jenkins-Team mit.

Ähnliche Vorwürfe äußerte auch Jeff Gehlbach, von OpenNMS. Breen hätte die betroffenen Projekte zunächst über die Zero-Day-Lücke informieren müssen, bevor er sie öffentlich bekannt machte. Justin Kennedy von Foxglove verteidigte sich damit, dass man die Schwachstelle nicht als Zero-Day-Lücke eingestuft habe.

Apache Commons selbst hat seinen 3.2.x-Zweig um einen vorgeschlagenen Patch erweitert, sodass sich die Serialisierung der anfälligen InvokerTransformer-Klasse per Flag standardmäßig deaktivieren lässt. “Bei Verwendung der neuen Version der Bibliothek resultiert jeder Versuch, einen InvokerTransformer zu deserialisieren, in einer Ausnahme”, wie Apache-Commons-Entwickler Thomas Neidhart erläutert.

[mit Material von Björn Greif, ZDNet.de]

Tipp: Kennen Sie die Geschichte der Computerviren? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de

Anklicken um die Biografie des Autors zu lesen  Anklicken um die Biografie des Autors zu verbergen