Java-Leck gefährdet zahlreiche Anwendungen
Die Behebung dieser Schwachstelle könnte sich als komplex erweisen. Erste Projekte haben jetzt bereits Patches für das verbreitete Leck in Java angekündigt.
Über ein Leck in der Apche-Commons-Bibliothek lässt sich Schad-Code in Java-basierte Anwendungen wie JBoss, Jenkins, OpenNMS, WebSphere oder WebLogic einführen. Das berichten Sicherheitsforscher von Foxglove Security. Die Schwachstelle beruht auf einer unsicheren Methode, mit der Java Objekte deserialisiert.
Die Lücke sei schon seit über neun Monaten bekannt, wie Foxglove in einem Blog erklärt. Weil Java-Anwendungen abhängige Bibliotheken mit jeder Applikation bündeln, statt Shared Libraries zu nutzen, ist die Schwachstelle schon seit einiger Zeit mit hoher Wahrscheinlichkeit ausnutzbar.
“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.
Beim Deserialisieren von Objekten durch Java, 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 Björn Greif, ZDNet.de]
Tipp: Kennen Sie die Geschichte der Computerviren? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de
