Java im Browser abschalten – diesmal wirklich

Keine Zeit? Hier die Kurzversion in 30 Sekunden.

• Am 10. Januar 2013 wurde eine weitere, aktiv ausgenutzte Lücke in Java 7 bekannt (CVE-2013-0422, betroffen bis Update 10).
• US-CERT empfahl, Java im Browser zu deaktivieren; Mozilla hat das Plug-in per Blockliste auf Click-to-Play gesetzt.
• Oracle hat inzwischen ein Update nachgeschoben (7u11). Ob es das letzte Loch war, weiß niemand.
• In der Java-Systemsteuerung gibt es seit 7u10 den Schalter, Java-Inhalte im Browser komplett auszuschalten.
• Meine Meinung: Applets haben im Alltag keine Zukunft. Server-Java ist davon nicht betroffen.

Im September habe ich hier geschrieben, man solle das Java-Plug-in im Browser abschalten, wo man es nicht zwingend braucht. Damals war das ein Rat mit einem gewissen Zögern, schließlich gab es mit Update 7 gerade eine Korrektur. Jetzt, ein paar Monate später, ist die nächste Lücke da, und diesmal fällt mir kein Zögern mehr ein.

Was passiert ist

Am 10. Januar wurde bekannt, dass in Java 7 bis einschließlich Update 10 eine Schwachstelle steckt (CVE-2013-0422), die schon aktiv ausgenutzt wird. Das Muster kennt man vom letzten Mal: Eine präparierte Webseite lädt ein Applet, das aus der Sandbox ausbricht und auf dem Rechner beliebigen Code ausführt. Nach den Berichten ist Java 6 davon nicht betroffen, das Problem steckt in neuem Code von Java 7. Der Exploit fand sich schnell in den gängigen Angriffswerkzeugen.

Die Reaktionen waren deutlicher als im Herbst. US-CERT hat öffentlich empfohlen, Java im Browser zu deaktivieren. Mozilla hat das Plug-in auf die Blockliste gesetzt, sodass Firefox es nicht mehr einfach so ausführt, sondern erst nach einem Klick des Nutzers (Click-to-Play). Wenn ein Browserhersteller ein verbreitetes Plug-in so behandelt, ist das ein ziemlich klares Signal. Oracle hat inzwischen ein Update nachgeschoben, es trägt die Nummer 7u11. Wer Java 7 im Browser hat, sollte es einspielen, aber dazu gleich mehr.

Der neue Schalter

Ironischerweise hatte Oracle mit 7u10 kurz vorher selbst nachgebessert. In der Java-Systemsteuerung gibt es auf dem Reiter Sicherheit seitdem einen Schieberegler für die Sicherheitsstufe, und es gibt den Haken „Java-Inhalte im Browser aktivieren“. Nimmt man ihn heraus, laufen Applets und Web-Start-Inhalte aus dem Browser nicht mehr, und zwar in allen Browsern auf einmal. Das ist viel bequemer als die Suche in den Add-on-Listen von drei verschiedenen Programmen. Die Sicherheitsstufe selbst ist eine gute Idee: Unsignierte Applets lassen sich damit sperren oder nur nach Rückfrage erlauben. Gegen eine Lücke in der Sandbox hilft sie allerdings nur, solange der Angriff die Abfrage nicht umgeht, und genau darauf würde ich mich nicht verlassen.

Wer es prüfen will: Systemsteuerung öffnen, Java wählen, Reiter Sicherheit. Auf Rechnern mit älteren Versionen fehlt der Haken, dort bleibt nur das Abschalten im Browser selbst.

Was ich davon halte

Ich werde bei diesem Thema langsam ungeduldig. Zweimal innerhalb weniger Monate dasselbe Muster, und beide Male war es die Applet-Sandbox, die versagt hat. Ein Update ist jedes Mal nötig, aber es ändert nichts daran, dass hier ein sehr großes Stück Code die Aufgabe hat, fremden Code aus dem Netz sicher in Schach zu halten. Das ist eine anspruchsvolle Konstruktion, und die bisherige Bilanz spricht nicht dafür, dass sie sich dauerhaft dichtmachen lässt.

Dazu kommt die praktische Seite: Wer benutzt noch Applets? Die meisten Webseiten kommen ohne aus, Flash und JavaScript decken die Fälle ab, für die man früher Java brauchte, und HTML5 nimmt dem Ganzen weitere Argumente. Es bleiben Nischen wie manche Banking-Seiten, Behördenformulare oder Fernwartungsoberflächen von älteren Geräten. Die kann man bewusst behandeln, statt das Plug-in für alle Seiten offen zu lassen.

Pro und Contra für das Abschalten sind für mich inzwischen ziemlich einseitig:

• Dafür: Die Angriffsfläche im Browser verschwindet, und die allermeisten Nutzer merken es nicht einmal.
• Dafür: Man muss nicht bei jedem Zero-Day raten, ob das nächste Update reicht.
• Dagegen: Einzelne Seiten gehen nicht mehr, vermutlich genau dann, wenn man sie braucht.
• Dagegen: Für die Nischenfälle muss man sich einen Weg einrichten, etwa einen zweiten Browser.

Für diesen zweiten Browser, der nur für die wenigen Java-Seiten gedacht ist und sonst nicht zum Surfen dient, ist das Plug-in dann vertretbar, vorausgesetzt, er ist aktuell. Alle anderen Browser bleiben sauber.

Server-Java ist ein anderes Thema

Ich sage das noch einmal, weil es in den Diskussionen gern durcheinandergeht: Es geht um das Plug-in im Browser. Ein Tomcat, ein Anwendungsserver oder ein Programm, das man selbst schreibt und lokal startet, lädt keinen fremden Code von beliebigen Webseiten nach. Dort ist die Laufzeitumgebung ein normales Stück Infrastruktur, das man wie jede andere Software aktuell hält. Wer aus der Meldung folgert, Java insgesamt sei kaputt, schüttet das Kind mit dem Bade aus. Wer aber folgert, das Applet im Browser sei kein sinnvolles Risiko mehr, liegt meiner Meinung nach richtig.

Ob 7u11 die Sache wirklich beendet, kann ich nicht beurteilen. Wahrscheinlich nicht endgültig. Deshalb: Haken raus, Update trotzdem einspielen, und wer ein Applet entwickelt oder betreibt, sollte sich ernsthaft fragen, ob es dafür nicht eine Lösung ohne Plug-in gibt.

Beitragsbild: eigene Collage mit Logos von Wikimedia Commons (Firefox-Logo: Sean Martell für Mozilla, CC BY 3.0); die Marken gehören ihren Inhabern.