Der Hype um die Java Security Bugs: Was ist wirklich dran am Sicherheitsrisiko Java?

Hartmut Schlosser

„Schalten Sie Java im Browser aus“, rät Sicherheitsexperte Carsten Eilers auf JAXenter. „Oracle muss dramatisch etws ändern oder es läuft Gefahr, dass Java in einem Sturm von Protest weggewischt wird“, schreibt Roger Grimes auf InfoWorld. Ob diesen beunruhigenden Signalen fragt sich derzeit die gesamte IT-Welt: Was ist wirklich dran am Sicherheitsrisiko Java?

Tatsache ist, dass das letzte Sicherheitsloch in Java SE 7 eine Medien-Präsenz hatte, wie nie ein Java Bug zuvor. Allerdings hatte auch nie zuvor das US-amerikanische Department of Homeland Security (etwa: Ministerium für innere Sicherheit) vor einem Java Bug gewarnt:

This and previous Java vulnerabilities have been widely targeted by attackers, and new Java vulnerabilities are likely to be discovered. To defend against this and future Java vulnerabilities, consider disabling Java in web browsers until adequate updates are available.

Reuters nahm dankend den Ball auf und zitierte in einem Artikel den Sicherheitsexperten Adam Gowdiak: Man wage es selbst nach dem letzten Java-Patch durch Oracle nicht, Usern zu sagen, es sei wieder sicher, Java zu aktivieren. Auf www.networkworld.com kommt Rapid7-Sicherheitsbeauftragter HD Moore zu Wort, der behauptet, Oracle könne zwei Jahre benötigen, um alle Sicherheitslücken in der Browser-Version von Java zu beheben.

Was von diesen Aussagen ist Hype, was Wirklichkeit?

Nun, eine objektive Analyse der Situation ergibt zunächst einmal Folgendes:

Java ist auf einer unglaublich hohen Anzahl von Desktop-Computern und Telefonen installiert. Schätzungen zufolge liegen die Zahlen bei über einer Milliarde Installationen auf Desktops und über 3 Milliarden Installationen auf mobilen Endgeräten. Das allein macht Java für Hacker interessant. Und so hat Java mittlerweile den Adobe Reader und Flash Player als häufigstes Angriffsziel für Hacker abgelöst.

Allerdings muss angemerkt werden, dass die Java-Plattform anders als die Adobe-Programme aus einer komplexen Struktur unterschiedlicher Komponenten besteht: JVM, Runtime-Umgebung, Garbage Collector, Bytecode Compiler, Security Sandboxes, etc. Zudem sind Browser Applets, Enterprise Server und mobile Anwendungen völlig unterschiedliche Ausprägungsformen von Java-Anwendungen. Attacken richten sich typischerweise immer gegen bestimmte Java-Komponenten, JVM-Versionen und/oder Anwendungsformen. Die jüngsten Sicherheitsprobleme betrafen etwa Applets in Browsern. Desktop-Anwendungen und Server-seitige Anwendungen sind vergleichsweise selten von Sicherheitsproblemen betroffen (obwohl natürlich auch Java Servlets oder Beans angegriffen werden).

Dennoch stehen wir momentan vor dem Sachverhalt: Obwohl Java explizit mit der Sicherheitsproblematik im Hinterkopf konzipiert wurde, ist es heute das Top-Ziel für Cyberkriminelle. Drei Faktoren nennt Roger Grimes in seinem InfoWorld-Artikel, die Javas Sicherheit kompromittieren: Erstens war das ursprüngliche Sicherheitsmodell so restriktiv, dass es selbst einfache Aufgaben behinderte (z.B. eine Datei auf dem Desktop abspeichern) – und musste deshalb aufgelockert werden. Zudem geht die beschriebene Komplexität von Java auf Kosten der Sicherheit. Außerdem wird Java regelmäßig um neue Funktionalität ergänzt, um wettbewerbsfähig zu bleiben – was jedes Mal neue Angriffsflächen bietet.

Doch das wahrscheinlich größte Problem besteht darin, dass den meisten Consumern das Vorhandensein von Java auf ihren Geräten gar nicht bewusst ist. Selbst wenn Sicherheitspatches zur Verfügung stehen, werden diese nicht eingespielt – denn wieso sollte ich etwas updaten, von dessen Existenz ich gar nichts weiß? Die Sicherheitsfirma Rapid7 spricht in einer Studie von 65% der Java-Installationen, die nicht auf den neuesten Stand gebracht worden sind – ein Paradies für Cyberkriminelle, die die hohe Erfolgsrate für Java-Attacken loben.

Aber auch im Enterprise-Bereich hält sich die Update-Freudigkeit in Grenzen. In Wahrheit bedeuten Updates gerade im Unternehmensumfeld einen oft nicht eingeplanten und deshalb ärgerlichen Mehraufwand. Haben Sie beispielsweise das letzte Java SE 7u11 schon eingespielt? Aber wahrscheinlich sind Sie ohnehin noch auf Java 6 – doch gilt auch hier die Frage: mit dem neuesten Sicherheitsupdate? Um diese Situation zu verbessern, rät Roger Grimes jedem Unternehmen, ein spezialisiertes Projekt-Team für Sicherheitsfragen einzurichten:

Without those requirements, you’re going to fail and the exploits (most of which would be blocked by patches) will continue to take down your computers.

Übrigens beruhigt Grimes die besorgten Gemüter auch ein wenig:

Wirklich gefährlich virulente Attacken werden in der Regel durch sich selbst replizierende Würmer bzw. Virus-Formen gefahren – etwa geschehen in den weltweiten Infektionen durch MS.Blaster oder SQL.Slammer. Java Exploits hingegen betreffen üblicherweise immer nur einzelne Maschinen, keine ganzen Netzwerke. Wenn Java-Attacken Interaktionen mit Usern benötigen, um sich weiter zu verbreiten, ist dies die beste Schranke gegen weltweite Infektionswellen. Im jüngsten Patch durch Oracle wird die Sicherheitseinstellung per Default auf „High“ gestellt, was auch bewirkt, dass Applets nicht automatisch ausgeführt werden sondern eine Bestätigung vom User verlangen.

Wohin sich Malware entwickelt, lässt sich freilich nicht wirklich vorhersagen. Dass Hacker auf weitere Bugs in Java hinweisen und raten, Java sei die zuverlässigere Angriffsfläche als die Browser, in denen die Java-Plug-ins laufen, klingt nicht gerade beruhigend – genauso wenig, dass Exploit Kits mit Java Bugs werben und auf dem Schwarzmarkt hohe Summen für Zero-Day-Exploits in Java gezahlt werden.

Ganz abgesehen von den realen Gefahren ist jedenfalls bedenklich, dass Java-Unternehmen auf der ganzen Welt derzeit darüber nachdenken, ob sie mit ihren Java-Programmen noch auf der sicheren Seite sind. Diesem drohenden Image-Verlust von Java gilt es vehement entgegenzutreten, sonst nimmt die Java-Community im ganzen Schaden – trotz des aktuellen Aufwinds durch das lang ersehnte Java 7, den Lambda-Ausdrücken im kommenden Java 8 und den spannenden Neuerungen in Java EE 7. Oracle hat mit dem außerordentlichen Java SE 7u11 Patch dieses Mal schnell auf die schlechte Presse reagiert. Ein nächster Schritt wäre es nun, den unseligen weil zu langsamen 4-Monats-Rhythmus für Sicherheitspatches offiziell ad acta zu legen und offensiv einen neuen, agilen Sicherheitsservice einzurichten, der darauf abzielen muss, zu den besten der Welt zu gehören.

Java war einmal das sichere C++ für alle Plattformen. Diesen Ruf muss sich die Enterprise-Sprache Nr.1 nun erst wieder verdienen.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.