Das Java-Problem ist nur ein Teil der Browser-Sicherheitsproblematik

Anfang Januar hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfohlen Java zumindest vorerst zu deaktivieren und Hinweise gegeben, wie sich die Java-Plug-ins in den gängigen Browsern abschalten lassen. „Java ist ein Durcheinander. Es ist nicht sicher. Sie müssen es abschalten“, wird auch der Sicherheitsexperte Jaime Blasco von den AlienVault Labs anlässlich neuester „Java- Sicherheitslücken“ zitiert.

Das ist sicher eine Übertreibung und zeugt selbst von gedanklichem Durcheinander, betreffen doch die Sicherheitslücken weder Java-Servlets, die auf Applikationsservern laufen, noch Java-Programme, die auf einem lokalen Rechner ausgeführt werden (meist als .jar-Datei). Die diskutierten Gefahren drohen einzig und allein bei der Nutzung der Java Laufzeitumgebung (Java Runtime Environment, JRE) mit Java-Applets im Browser.

Tobias Frech, stellvertretender Vorstand des Interessenverbunds der Java User Groups iJUG) in Deutschland (Bild: iJUG).

„Ein Benutzer konnte bis vor kurzem in Version 7 über diese Applets mit Schadsoftware in Kontakt kommen, wenn beispielsweise der auf der Webseite verwendete Werbedienst die Auslieferung von Java-Applets zugelassen hat“, umreißt Tobias Frech, stellvertretender Vorstand des Interessenverbunds der Java User Groups (iJUG) in Deutschland das Problem. Frech beruhigt aber insofern, als „bei Installation von Update 10 oder 11 die Sicherheitslücken deutlich unkritischer geworden sind“.

Zum einen schließe das Update 11 die im Internet bisher ausgenutzte Sicherheitslücke in Java-Applets, zum anderen sei mit der Veröffentlichung von Update 11 ein Sicherheitsmechanismus in Update 10 aktiviert worden, durch den Anwender einer Ausführung von Applets ohne Quellenangabe erst einmal explizit zustimmen müssten. „Sollten sich die Gerüchte über weitere Lücken in Update 11 bewahrheiten, so wären die Benutzer immer noch durch die vorherige Abfrage vor der Ausführung von Applets geschützt“, meint Frech.

Kein Unternehmen, das Java einsetzt, muss also „alles abschalten“ und auch solche Unternehmen, die speziell Java-Applets im Browser nutzen, können sich vernünftig absichern. Freilich müssen die Unternehmen die Updates einspielen. „Patchmanagement ist ganz wichtig“, sagt Dirk Kollberg, Senior Threat Researcher bei Sophos in Hamburg, und er fügt hinzu: „Wenn man darüber hinaus weitere Sicherheitsmaßnahmen ergreifen will, dann kann man beispielsweise mit zwei Browsern arbeiten, die unterschiedlich konfiguriert sind.“

Für Unternehmen, die wichtige Applikationen auf der Basis von Java-Applets betreiben, können sich solche Zwei-Browser-Lösungen auf jeden Fall rentieren, zumal sie natürlich auch für andere unsichere Software-Kantonisten wie Adobe Flash Player etc. verwendet werden können.

Dirk Kollberg, Senior Threat Researcher bei Sophos in Hamburg (Bild: Sophos GmbH)

In bestimmten Konstellationen können sich sogar sehr aufwändige Sicherheitslösungen rechnen, wie sie beispielsweise das Bundesamt für Sicherheit in der Informationstechnk (BSI) und der Saarbrücker Sicherheitsspezialist Sirrix vorschlagen beziehungsweise anbieten. Das ist zum einen die Nutzung eines eigenen Terminalservers für den Browser (Remote Controlles Browsers System, ReCoBS) und zum anderen eine Browserlösung in einer virtuellen Maschine („Browser in the Box„) auf dem lokalen Rechner.

Admin-Programme arbeiten oft mit Java-Applets

Bei der Ab- und Einschätzung, inwieweit die Nutzung von Java-Applets in Unternehmen überhaupt eine Rolle spielt, unterscheiden sich die Experten, zumindest was den Grad dieser Nutzung betrifft. „Java-Applets spielen nach unserer Erfahrung in den Unternehmen keine dominante Rolle“, meint Stefan Strobel, Geschäftsführer des Heilbronner IT-Sicherheitsspezialisten Cirosec.

Tobias Frech von der iJUG sieht das ein bisschen anders: „Java im Web-Browser wird in Unternehmen in überraschend vielen Web-Anwendungen verwendet. Die Palette reicht dabei von bekannten Web-Konferenzlösungen über Konfigurationsprogramme für spezialisierte Hardware und benutzerfreundliche Texteditoren für Content-Management-Systeme bis hin zum Einsatz bei Elster Online für die elektronische Steuererklärung.“

Kaum unterschiedliche Einschätzungen bei den Experten gibt es darin, dass die Java-Laufzeitumgebung und Applets im Browser bei Administrationsprogrammen eine wichtige Rolle spielen. „Für die Verwaltung von Switches, WLAN-Zugangspunkten und ähnlichen Netzwerk-Tools kommen bei den Firmen oft Programme zum Einsatz, die mit Java im Browser arbeiten“, weiß Rolf Haas, Principal Security Engineer bei McAfee. Manche Hersteller von Admin-Werkzeugen setzten sogar bestimmte Versionen in der Java-Laufzeitumgebung voraus, sodass infolgedessen bei nicht wenigen Unternehmen mehrere JRE-Versionen installiert seien. Bei manchen Unternehmen gebe es sogar einen Software-Umschaltknopf zwischen den verschiedenen JRE-Versionen.

Ein geordnetes Update-Management ist unter solchen Umständen schwierig bis unmöglich. Das liegt aber nicht nur an der Versionsbindung mancher Admin-Tools, sondern auch daran, dass „viele IT-Abteilungen mit dem Nachziehen der Updates nicht hinterherkommen“, hat Haas beobachtet. McAfee selbst verfüge mit Host-Intrusion-Prevention-Systemen über Schutzmechanismen, die beispielsweise Buffer-Overflows und damit verbundene Zero-Day-Attacken erkennne könnten. Im Übrigen habe man hausintern mittlerweile nur noch eine Konsole, die JRE benötigt.

Stefan Strobel, Geschäftsführer des IT-Sicherheitsspezialisten Cirosec (Bild. Cirosec).

Ob der der gänzliche Verzicht auf die Verwendung von Java-Applets wirklich die Lösung des Problems ist, kann durchaus bezweifelt werden. Denn zum einen bringt ein zeitnahes Update-Management ausreichend Sicherheit und zum anderen gibt es noch nicht für alle Java-Applet-Anwendungen derzeit eine wirkliche Alternative.

So ist nach Einschätzung von Tobias Frech von der iJUG „bisher keine Alternative mit ausreichender Verbreitung bekannt, die es Webanwendungen ermöglichen würde, mit externen Geräten wie beispielsweise Kartenlesern oder anderer Hardware zu interagieren“. Mit der Weiterentwicklung von HTML 5 und REST-Ansätzen kann sich das nach Frechs Meinung in der Zukunft ändern. Auch Björn Höfling, freiberuflicher Java-Spezialist in München, meint, dass die Sicherheitsprobleme der Java- Laufzeitumgebung „langfristig für ein Aussterben der Java-Applets und ein Umsteigen auf HTML5 sorgen könnten.“ Er hält HTML5 als Java-Applet-Nachfolger für sehr geeignet, vor allem auch, wenn es künftig für mobile Endgeräte ausgelegt ist.

Neue Wege für die Browsersicherheit

Die Diskussion um die Sicherheitslücken in der Java-Laufzeitumgebung war und ist richtig und wichtig, auch wenn sie nicht neu ist und manche Stellungnahme weniger von der Sorge um Sicherheit als aus Ärger über (aus Sicht des Autors scheinbare) Änderungen der Java-Politik von Oracle geleitet sein mögen. Für Updates der mittlerweile abgekündigten Version 6 ist mittlerweile ein Wartungsvertrag notwendig, für die Version 7 wird es aber weiterhin kostenlose Updates bezüglich Sicherheit und neuer Funktionalität geben.

Richtig und wichtig ist die Diskussion auch deshalb, weil sie den Kopf frei macht für eine breitere Diskussion, nämlich über Browser-Sicherheit im Allgemeinen. „Ob nun Java-Applets oder Adobe Flash Player, wir haben das Problem eigentlich ständig“, sagt Stefan Strobel von Cirosec und erfährt fort: „Die Angriffe laufen immer weniger über Web- oder Mailserver, die mittlerweile gut gesichert sind, sondern über den Browser. Die Client-Seite ist heute das beliebteste Angriffsziel.“

Tobias Frech äußert sich in der gleichen Weise und definiert die Richtung, in die seiner Meinung die diesbezügliche Entwicklung gehen sollte: „Über die Sicherheitskonzepte auf Endgeräten muss neu nachgedacht werden. Eine Isolation von unterschiedlich kritischen Anwendungsbereichen bezüglich Daten und Anmeldeinformationen sollte in die Basis der Systeme, also zum Beispiel ins Betriebssystem, aufgenommen werden. Diese Isolation ist bisher nur relativ umständlich über den Einsatz verschiedener virtueller Maschinen erreichbar und sollte praktikabler gemacht werden.“ Das ist zweifellos eine Herausforderung, die für alle IT-Systeme gilt, egal ob sie auf Java basieren oder nicht.