Die 10 größten Sicherheitslücken in Java [2019 – Liste]

Unsere Freunde von OverOps veröffentlichen jedes Jahr einen Blogbeitrag mit einer Rangliste der beliebtesten Java-Bibliotheken, basierend auf Erwähnungen auf GitHub. In diesem Beitrag werfen wir deshalb einen Blick auf die Sicherheitslücken in den zehn beliebtesten Java-Bibliotheken laut OverOps und gehen bei drei davon näher ins Detail. Zunächst die zehn beliebtesten Bibliotheken von OverOps, sortiert nach Popularität:

1. Jackson

2. Hadoop

3. org.junit

4. org.junit.runner

5. org.springframework

6. Jetty

7. com.amazonaws.services

8. org.apache.http.client

9. org.apache.shiro

10. org.apache.commons.lang3

Laut unserer Snyk Vulnerability Database wurden im Laufe der Zeit insgesamt 162 Sicherheitslücken in diesen zehn Bibliotheken offengelegt. Wir sehen uns die Bibliotheken Jackson, Spring Framework und Jetty genauer an und betrachten, wie sich ihre Sicherheitslücken über die verschiedenen Releases verteilen. Außerdem werfen wir einen Blick auf Schweregrad und Art der Sicherheitslücken in jeder Bibliothek. Diese drei Beispiele sind besonders interessant, da sie die bedeutendsten offengelegten Sicherheitslücken aufweisen und bekannte Schlüsselbibliotheken sind, die in vielen Anwendungen in der Produktion zum Einsatz kommen.

Wenn Snyk Ihre Java-Projekte überwacht, wurden Sie in Ihren Snyk-Scans bereits über Sicherheitslücken informiert. Falls nicht, können Sie kostenlos prüfen, ob Ihre Anwendung von den in diesem Beitrag erwähnten Sicherheitslücken betroffen ist: Testen Sie Ihr Anwendungs-Code-Repository mit Snyk.

Sicherheitslücken in Jackson

Die Liste der beliebtesten Bibliotheken hat sich 2018 gegenüber dem Vorjahr leicht verändert: Jackson steht diesmal ganz oben. Jackson ist ein weitverbreitetes Datenverarbeitungspaket, das häufig zum Parsen von JSON in Java-Anwendungen verwendet wird.

Im Laufe der Zeit wurden in der Bibliothek insgesamt 21 Sicherheitslücken entdeckt. Bei den meisten handelt es sich um die Deserialisierung nicht vertrauenswürdiger Daten.

Bei der Deserialisierung werden Dateien wie JSON oder XML empfangen und anschließend in ein Format umgewandelt, das von der Hosting-Anwendung verarbeitet werden kann. Eine Sicherheitslücke durch die Deserialisierung nicht vertrauenswürdiger Daten (CWE-502) liegt vor, wenn eine Anwendung Daten deserialisiert, die nicht aus einer vertrauenswürdigen Quelle stammen, ohne ausreichend zu prüfen, ob sie gültig sind. Dadurch kann ein Angreifer den Zustand oder den Ablauf der Ausführung kontrollieren.

Probleme mit der Java-Deserialisierung sind seit Jahren bekannt. Das Interesse an diesem Thema nahm 2015 jedoch deutlich zu, als in einer beliebten Bibliothek (Apache Commons Collection) Klassen entdeckt wurden, die sich für Remote Code Execution missbrauchen ließen. Diese Klassen kamen bei Zero-Day-Angriffen auf IBM WebSphere, Oracle WebLogic und viele weitere Produkte zum Einsatz.

Deserialisierung ist ein leichtes Angriffsziel: Jede Anwendung kann kompromittiert werden, sofern sie eine anfällige Klasse in ihrem Klassenpfad enthält und nicht vertrauenswürdige Daten deserialisiert. Der Angreifer sendet einfach die Nutzdaten an den Deserialisierer, woraufhin der Befehl ausgeführt wird.

Nahezu jede damit verbundene Sicherheitslücke wird als schwerwiegend eingestuft, da es in den meisten Fällen um die Deserialisierung nicht vertrauenswürdiger Daten geht. Diese gehört zu den schwerwiegendsten Arten von Sicherheitslücken auf der CVSS-Skala.

Sind Sie betroffen?

Die aktuelle Version von Jackson, 2.9.9, enthält tatsächlich keine einzige bekannte Sicherheitslücke. Das ist ein gutes Zeichen für eine gut gepflegte, beliebte Bibliothek: Gemeldete Sicherheitslücken erhalten offensichtlich die nötige Aufmerksamkeit und werden schnell behoben. Prüfen Sie jetzt kostenlos mit Snyk, ob Ihre Java-Anwendungen betroffen sind. Sie erhalten außerdem Empfehlungen zur Behebung und zur nächstgelegenen sicheren Version, auf die Sie aktualisieren sollten.

Sicherheitslücken im Spring Framework

Das Spring Framework ist zweifellos das beliebteste Web-Framework für moderne Java-Anwendungen und wird von Millionen Entwicklerinnen und Entwicklern genutzt. Es ist nicht nur eine Bibliothek, sondern ein ganzes Ökosystem mit verschiedenen Komponenten. Angesichts der weiten Verbreitung dieses Ökosystems erscheinen die Zahlen zu Sicherheitslücken gar nicht mehr so hoch. In den Jahrzehnten, seit es das Spring Framework gibt, wurden insgesamt nur 96 Sicherheitslücken entdeckt. Die folgende Grafik zeigt, wie sich die entdeckten Sicherheitslücken auf die verschiedenen Framework-Versionen verteilen:

Wie Sie sich vorstellen können, dauert es, Sicherheitslücken zu finden. Deshalb blieben viele über mehrere Versionen hinweg in der Bibliothek, bevor sie behoben wurden. Sie wurden für jede Version gezählt, in der sie entdeckt wurden. Daher summieren sich die oben genannten Zahlen nicht auf 96. Aus demselben Grund sinkt die Zahl der Sicherheitslücken bei den aktuellen Versionen: Wahrscheinlich gibt es noch weitere, die bislang nicht entdeckt wurden.

Die meisten Sicherheitslücken werden als schwerwiegend oder mittelschwer eingestuft. Das ist bei einer Bibliothek oder einem Framework mit zahlreichen Funktionen für Anwendungen – darunter Unterstützung für Endpunkte, Transport und Sicherheit – durchaus üblich.

Sehen wir uns nun die Arten dieser Sicherheitslücken an. Unten listen wir alle Arten auf, die in der Geschichte des Spring Framework mindestens fünfmal aufgetreten sind. Die Bandbreite ist recht groß, was erneut auf den umfassenden Funktionsumfang des Spring Framework zurückzuführen ist. Erwähnenswert ist außerdem die Sicherheitslücke Arbitrary Code Execution, die manchmal durch die Ausnutzung der Spring Expression Language (SPEL) entsteht, wie bei dieser Sicherheitslücke für Arbitrary Code Execution, die auch als „Spring Break“ bezeichnet wird.

Sind Sie betroffen?

Als Best Practice sollten Sie immer auf die neuesten für Ihre Anwendung verfügbaren Versionen aktualisieren. Aus verschiedenen Gründen geschieht das jedoch nicht immer regelmäßig. Häufig werden Bibliotheken oder Frameworks bei Bedarf aktualisiert, manchmal auch, um eine Sicherheitslücke zu beheben – da kann es schwierig sein, Schritt zu halten. Prüfen Sie jetzt kostenlos mit Snyk, ob Ihre Spring-Anwendungen betroffen sind. Sie erhalten außerdem Empfehlungen zur Behebung und zur nächstgelegenen sicheren Version, auf die Sie aktualisieren sollten.

Sicherheitslücken in Jetty

Das Projekt Eclipse Jetty wird manchmal als Bibliothek, aber wahrscheinlich häufiger als schlanker Anwendungsserver verwendet – oft vom Spring-Boot-Framework, das mit dem zuvor erwähnten Spring Framework zusammenhängt. Jetty wird seit mehreren Jahrzehnten entwickelt und verfügt über eine große Community aus Nutzenden und Mitwirkenden. Im Laufe der Jahre wurden im Jetty-Projekt 38 Sicherheitslücken entdeckt. Mehr als die Hälfte davon entfällt auf kryptografische Probleme (13) oder die Offenlegung von Informationen (6). Angesichts des Zwecks von Sicherheitskomponenten können Fehler häufig ebenfalls zu Sicherheitsproblemen führen. Unten finden Sie die vollständige Liste der Arten von Sicherheitslücken, die im Jetty-Projekt mehr als einmal aufgetreten sind.

Sind Sie betroffen?

Am besten finden Sie heraus, ob Sie von diesen Sicherheitslücken oder von Sicherheitslücken in den transitiven Abhängigkeiten Ihrer Abhängigkeiten betroffen sind, indem Sie jetzt kostenlos mit Snyk testen. Sie erhalten außerdem Empfehlungen zur Behebung und zur nächstgelegenen sicheren Version, auf die Sie aktualisieren sollten.

Bei Snyk möchten wir Entwicklerinnen und Entwicklern das Testen ihrer Projekte erleichtern. Deshalb bieten wir Integrationen für Ihre bevorzugten IDEs, Code-Repositories wie GitHub, GitLab und BitBucket, CI-Server und vieles mehr. Sie können kostenlos testen. Wir hoffen, dass Sie die automatischen Funktionen zur Behebung nutzen, um auf eine sicherere Version zu aktualisieren. Bleiben Sie sicher!