Lücke in Apache-Commons-Bibliothek gefährdet Java-Anwendungen

Sicherheitsforscher von Foxglove Security haben auf eine Lücke in der häufig genutzten Apache-Commons-Bibliothek hingewiesen, die sich zum Einschleusen und Ausführen von Schadcode ausnutzen lässt. Die Schwachstelle beruht auf einer unsicheren Methode, mit der Java Objekte deserialisiert. Sie gefährdet Java-basierte Anwendungen wie JBoss, Jenkins, OpenNMS, WebSphere oder WebLogic.

Wie Foxglove in einem Blogbeitrag erklärt, ist die Lücke schon seit über neun Monaten bekannt. Weil Java-Anwendungen abhängige Bibliotheken mit jeder Applikation bündeln, statt Shared Libraries zu nutzen, dürfte sich die Schwachstelle schon seit einiger Zeit ausnutzen lassen.

„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. Er basiert ihm zufolge auf einer ähnlichen Lücke in Apache Commons im Zusammenhang mit der Deserialisierung von Objekten, die schon im Januar öffentlich gemacht wurde.

Basierend auf der Art, wie Java benutzerdefinierten Code beim Deserialisieren von Objekten ausführt, konnte Breen 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 verwenden.

Apache und Jenkins haben inzwischen reagiert, und Patches angekündigt, um die Schwachstelle zu beseitigen. Jenkins veröffentlichte einen Workaround, der das für den Angriff ausgenutzte Jenkins CLI System deaktiviert. Ein Patch soll kommenden Mittwoch erscheinen. „Unglücklicherweise wurden wir vor dem Veröffentlichung nicht über die Lücke informiert, so dass wir noch an einem Fix arbeiten“, teilte das Jenkins-Team mit.

Ähnliche Vorwürfe äußerte auch Jeff Gehlbach von OpenNMS, der via Twitter erklärte, Breen hätte die betroffenen Projekte zunächst über die Zero-Day-Lücke informieren müssen, bevor er sie öffentlich machte. Justin Kennedy von Foxglove antwortete darauf, dass man die Schwachstelle nicht als Zero-Day-Lücke betrachtet habe.

Apache Commons selbst hat seinen 3.2.x-Zweig um einen vorgeschlagenen Patch erweitert, so dass sich die Serialisierung der anfälligen InvokerTransformer-Klasse per Flag standardmäßig abschalten 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 erklärt.

[mit Material von Chris Duckett, ZDNet.com]

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