Jackson-Deserialisierungs-Schwachstelle

Am 29. Juli 2019 wurde eine Schwachstelle mit hohem Schweregrad veröffentlicht, die eine Deserialisierung nicht vertrauenswürdiger Daten ermöglichte (CVE-2019-14379, CVE-2019-14439) und alle Versionen von com.fasterxml.jackson.core:jackson-databind bis einschließlich 2.9.9.2 betraf.

Wenn Sie Spring Boot verwenden, beachten Sie, dass die aktuelle Version (2.1.7) vom älteren, anfälligen jackson-databind-Paket 2.9.9 abhängt.

Wir haben unsere Datenbank bereits aktualisiert, und die Maintainer des jackson-databind-Pakets haben eine Lösung entwickelt. Wenn Sie Snyk verwenden, wurden Sie bereits über diese Schwachstelle informiert. Das Team, das das jackson-databind-Paket betreut, hat hervorragende Arbeit geleistet und eine neue Version (2.9.9.3) veröffentlicht, die diese Schwachstelle nicht enthält. Der Snyk-Scanner empfiehlt diese Version als Abhilfe, sodass Sie nicht mehr betroffen sind.

Über die Schwachstelle

Das ist nicht das erste Mal, dass das jackson-databind-Paket von einer Schwachstelle betroffen ist, die eine Deserialisierung nicht vertrauenswürdiger Daten ermöglicht. Tatsächlich sind seit 2018 mehr als ein Dutzend solcher Schwachstellen bekannt und offengelegt worden. Fast alle gelten als besonders schwerwiegend.

Die Bibliothek dient hauptsächlich dazu, Java-Objekte in JSON und umgekehrt zu serialisieren. Das Problem entsteht beim Deserialisieren von JSON zurück in Java-Objekte. Kann eine schlecht programmierte Java-Anwendung einen JSON-String aus einer nicht vertrauenswürdigen Quelle deserialisieren, kann ein Hacker dies beispielsweise für eine Remote-Codeausführung ausnutzen.

Ist polymorphes Typing für Jackson aktiviert, kann ein Angreifer ein Gadget für seinen Angriff nutzen, wenn er die JSON-Eingabe kontrolliert. Ein Gadget ist eine Klasse oder Funktion, deren ausführbarer Code bereits im anfälligen Prozess vorhanden ist. Dieser vorhandene ausführbare Code lässt sich für böswillige Zwecke wiederverwenden.

Bei dieser konkreten Schwachstelle konnte ein Gadget aus Ehcache missbraucht werden, wenn das Standard-Typing in Jackson aktiviert war. Die Maintainer von jackson-databind reagierten schnell und fügten das betreffende Gadget der bereits bestehenden Blacklist hinzu. Version 2.9.9.3 wurde veröffentlicht und enthält diese Schwachstelle nicht mehr.

Spring Boot

Zum Zeitpunkt der Veröffentlichung dieses Blogbeitrags ist Spring Boot in Version 2.1.7 verfügbar. Diese Version hängt vom älteren jackson-databind-Paket 2.9.9 ab.

Das bedeutet: Wenn Sie eine neue Spring-Boot-Anwendung mit dem Sping Boot Initialzr erstellen, wird mit Sicherheit eine anfällige jackson-databind-Version eingebunden.

Solange keine neue Version von Spring Boot oder spring-boot-starter-data-rest veröffentlicht wurde, können wir die jackson-databind-Versionen austauschen. Eine Möglichkeit ist, das einzelne Paket wie im folgenden Maven-Beispiel auszuschließen:

<dependencies>
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-data-rest</artifactId>
       <exclusions>
           <exclusion>
               <groupId>com.fasterxml.jackson.core</groupId>
               <artifactId>jackson-databind</artifactId>
           </exclusion>
       </exclusions>
   </dependency>
   <dependency>
       <groupId>com.fasterxml.jackson.core</groupId>
       <artifactId>jackson-databind</artifactId>
       <version>2.9.9.3</version>
   </dependency>
…
</dependencies>

„Eine bessere Lösung besteht darin, die Maven-Eigenschaft auf die passende Version festzulegen. Dadurch importiert Spring Boot die korrigierte Jackson-BOM (Bill of Materials), die alle einzelnen Jackson-Abhängigkeiten verwaltet. In einem Gradle-Projekt lässt sich etwas Vergleichbares in der Datei gradle.properties festlegen. Weitere Informationen zur Maven-BOM und dazu, warum sie für Spring Boot wichtig ist, finden Sie im Blogbeitrag: „Was ist eine Bill of Materials (BOM)-Datei?“

<properties>
    <jackson.version>2.9.9.20190807</jackson.version>
</properties>

Bibliotheken wie jackson-databind sind häufig indirekte Abhängigkeiten, die Teil eines größeren Frameworks sind. Deshalb empfiehlt es sich, Ihre Anwendungen insbesondere auf bekannte Schwachstellen in diesen indirekten Abhängigkeiten zu prüfen. Wenn Sie dies regelmäßig tun, wissen Sie, ob Sie betroffen sind, und können die Probleme gegebenenfalls beheben.