Kommentar zur sogenannten Sicherheitslücke in Apache Commons Collections

In den letzten Tagen hat die Nachricht über eine Sicherheitslücke in der weit verbreiteten Bibliothek Apache Commons Collections die Runde gemacht. Die Berichte gehen zurück auf die Präsentation „Marshalling Pickles – how deserializing objects will ruin your day“ auf der AppSecCali2015 von Gabriel Lawrence (@gebl ) und Chris Frohoff (@frohoff ). Kurz darauf gab das Apache-Commons-Projekt ein Statement dazu ab. Damit war die Sache eigentlich erledigt, aber da ich trotzdem von einigen Leuten darauf angesprochen wurde, möchte ich hier die Gelegenheit ergreifen, das Ganze noch einmal zu kommentieren. Der wichtigste Take-away vorweg: Es ist nicht Apache Commons Collections, das unsicher ist, sondern Anwendungen, welche die Java-Deserialisierung auf unsichere Art und Weise benutzen.

Kein einfacher Fix

Es ist wichtig zu verstehen, dass das Entfernen oder Austauschen von Apache Commons Collection aus der Anwendung oder vom Application Server diese nicht per se sicherer machen wird. Der Grund dafür ist, dass der von Lawrence und Frohoff beschriebene Angriff auch mit Klassen aus anderen populären Bibliotheken wie dem Spring Framework oder Groovy durchgeführt werden kann. Es gibt sogar eine Klasse im JDK selbst, welche dazu verwendet werden kann (nämlich com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl). Das ist natürlich schlecht, weil „Apache Commons Collections ist unsicher“ so viel einfacher ist als „eine Anwendung ist unsicher, wenn sie die Java Serialisierung auf eine unsichere Art verwendet“. Es gibt dementsprechend keinen einfachen Fix, sondern es muss im Einzelfall entschieden werden.

Der Angriff erklärt

Zunächst möchte ich hier noch einmal die Idee hinter dem Angriff von Lawrence und Frohoff erklären:
Der Angreifer erzeugt eine Map und dekoriert sie mit einer TransformedMap . Danach wird der TransformedMap eine spezielle Implementierung des Transformer Interface hinzugefügt. Diese verwendet Reflection um Werte zu transformieren (siehe InvokerTransformer ). Der InvokerTransformer wird dann instrumentiert um zum Beispiel Runtime.exec(String) aufzurufen. Die präparierte Map wird daraufhin mittels Java-Serialisierung an das Ziel geschickt. Dort angekommen wird der Binärstrom wieder zurück in Java-Objekte deserialisiert. Da bei der Java-Serialisierung im Binärstrom ebenfalls die Information enthalten ist, von welchen Klassen die enthaltenen Objekte instanziiert werden sollen, erzeugt der Empfänger keine simple HashMap, sondern eine TransformedMap inklusive InvokerTransformer. Wenn jetzt im Angriffsziel anderer Code auf die Map zugreift, werden die InvokerTransformer ausgelöst und der Angriff ist erfolgreich. Das alles zusammen bezeichnen Security Experten als „gadget chain“.

So weit, so gut. Fassen wir noch einmal zusammen, welche Bedingungen eine Anwendung erfüllen muss, damit sie anfällig für diesen Angriff ist:

• Apache Commons Collections muss sich im Classpath befinden – andernfalls schlägt die Deserialisierung fehl
• Die Anwendung muss einen Endpoint bereitstellen, welcher Binärdaten entgegennimmt und dann ohne weitere Prüfung Objekte daraus erzeugt
• Die Anwendung muss nicht vertrauenswürdigen Dritten ohne Autorisierung Zugriff auf den Endpoint geben

Es ist deshalb wichtig noch einmal zu unterstreichen, dass eine Anwendung nicht deshalb unsicher ist, weil sie Apache Commons Collections oder eine andere der genannten Bibliotheken verwendet. Anwendungen sind deshalb unsicher, weil sie nicht vertrauenswürdige Daten ohne weitere Prüfung entgegennehmen. Weil das grob fahrlässig ist, sind Lawrence und Frohoff gar nicht auf die Idee gekommen dies direkt dem Apache-Commons-Projekt zu melden. Trotzdem hat das Apache-Commons-Projekt bereits einen Bugfix für Apache Commons Collections 3.x bereit gestellt, in dem die Deserialisierung für den InvokerTransformer per Default deaktiviert ist (sie lässt sich per System Property explizit wieder aktivieren). Des Weiteren gibt es eine Diskussion darüber einen SafeObjectInputStream zu Apache Commons IO hinzuzufügen. Dieser erlaubt es anzugeben, welche Klasse deserialisiert werden dürfen, sofern eine Anwendung wirklich per Java-Serialisierung mit Dritten kommunizieren muss. Es bleibt aber festzuhalten, dass jede Anwendung individuell zu prüfen ist.

Bitte fair bleiben

Warum schreibe ich das also alles? Mir gefällt einfach die schlechte Presse gegen Projekte wie Apache Commons nicht. Zumal es sich hierbei ganz klar nicht um ein Problem in Commons Collections handelt, sondern in der Java-Serialisierung selbst. Hinter Projekten wie Apache Commons, Spring oder Groovy stecken Menschen, die viel Energie und nicht selten auch eine Menge ihrer Freizeit in die Entwicklung dieser Bibliotheken stecken. Die Bibliotheken sind von großem Nutzen für die gesamte Java-Community. Sie haben es verdient fair behandelt zu werden. Auch wenn das leider bedeutet, dass die Lösung für ein Security-Problem nicht so einfach ist. Also bitte helfen Sie mir diesen Unsinn zu beenden. Wenn Sie gefragt werden, ob eine Anwendung wegen Apache Commons Collections unsicher ist, dann erklären Sie ihrem Gegenüber, dass Deserialisierung nicht vertrauenswürdiger Daten unsicher ist – und nicht das Vorhandensein generell nützlicher Bibliotheken.

Ich danke es Ihnen.

(*) Ich meine hiermit nicht bloß EARs oder WARs, welche in einen Application Server deployt werden, sondern auch die Application Server selber.