Immer mehr Schwachstellen: Wie sich Java sicherer machen lässt

Java und speziell JRE gehören zu den beliebtesten Zielen auf der Anwendungsebene auf der Client-Seite und sollten entsprechend abgesichert werden.

Es ist kein Geheimnis: Angreifer haben sich in den letzten Jahren im Stack immer weiter nach oben gearbeitet. Denn weil Unternehmensnetze und -plattformen mittlerweile viel schwieriger zu durchdringen sind, bevorzugen Hacker inzwischen die niedrig hängenden Früchte in Form von Angriffen auf der Anwendungsebene. Denn hier herrscht kein Mangel an lohnenden Zielen.

Oracle selbst hat bei Java zusätzliche technische Altlasten geschaffen, die zu noch mehr Schwachstellen führen werden.

Zwei beliebte Ziele auf Client-Seite sind Flash und Adobe Reader. Doch das wohl beliebteste Ziel der Anwendungsebene ist Java und speziell das Java Runtime Environment (JRE). Oracle hat mit Sun die Entwicklung des Java-Ökosystems in vielen Bereichen vorangetrieben, unter anderem bei der Programmiersprache, Server-seitigen Umgebungen und der weiten Verbreitung von JRE auf der Client-Seite. Trotzdem finden sich immer wieder schwere Schwachstellen im JRE. Die meisten davon sind auf verbreitete Plattformen wie Mac OS und Windows begrenzt. Doch weil Java in einer Vielzahl von Plattformen für Client-Software zum Einsatz kommt, werden die Folgen der Schwachstellen nicht immer richtig verstanden.

In diesem Artikel berichten wir über die jüngste Welle an neu entdeckten Java-Schwachstellen. Außerdem stellen wir Maßnahmen vor, mit denen sich Java im Enterprise-Umfeld besser absichern lässt.

Ein Schritt vor, ein Schritt zurück

Zuletzt konnte man fast glauben, dass Angreifer immer dann, wenn Oracle gerade einen Patch für die neueste Java-Lücke veröffentlicht hatte, sofort eine neue Schwachstelle finden. Eine weitere schwere Schwachstelle wurde im September 2012 identifiziert: Über sie können Angreifer ein Kern-Sicherheitsfeature von Java JRE namens "Type Safety" ausnutzen, um aus der Java-Sandbox zu entkommen. Auf diese Weise kann ein Hacker die Sicherheit eines Systems vollständig kompromittieren.

Noch schlimmer ist, dass Sicherheits-Patches für Java-Angreifer womöglich selbst neue Einbruchsmöglichkeiten geben: Nach Berichten könnte die im August 2012 bekannt gewordene JRE-Schwachstelle erst durch einen früheren Patch entstanden sein. Der Bug in der AWT-Subkomponente von Java könnte auch eine Code-Ausführung im lokalen System ermöglichen, bei der die Sandbox umgangen wird – das System wäre kompromittiert. Wenn es durch den Update-Prozess für Software von Oracle zu neuen Schwachstellen kommt, stellt sich die Frage nach der Stärke des Software-Entwicklungszyklus' für Java. Nicht alle Bugs lassen sich vermeiden, aber um zumindest die nachträgliche Einführung von neuen zu verhindern, wäre wohl ein besseres Sicherheitskonzept für den Entwicklungszyklus vonnöten.

Zu erwarten ist jedenfalls, dass die Probleme mit Java-Sicherheit nicht einfach aufhören werden. Schwachstellen werden weiter gefunden, ausgenutzt und dann von Oracle mit schwankender Geschwindigkeit und Effizienz geschlossen werden. Um fair zu bleiben: Es ist für Oracle nicht leicht, die Entwicklung von Java voranzubringen und es gleichzeitig sicher zu halten. Noch schwieriger wird das durch die Tatsache, dass Oracle Java nicht nur samt Schwächen von Sun Microsystems übernommen hat. Der Software-Konzern selbst hat darin weitere technische Altlasten eingeführt, die zu noch mehr Schwachstellen führen.

Larry Ellison hat die Produkte seines Unternehmens einmal als "unverwüstlich" bezeichnet – doch diese Haltung zu Sicherheit scheint JRE nicht mit einzuschließen. Allgemein gilt die Sicherheitsphilosophie von Oracle als weniger ausgereift als die von Konkurrenten wie Microsoft oder Adobe. Das hat Einfluss auf die Art und Weise, wie Unternehmen JRE nutzen.

Microsoft und Adobe haben vor einiger Zeit damit begonnen, ihre Sicherheitskulturen zu verändern. Dabei realisierten sie – obwohl sie mit ähnlichen technischen Altlasten zu kämpfen hatten wie Oracle – durchaus Verbesserungen bei der Sicherheit ihrer Produkte. Oracle hat zwar eine lange Geschichte mit im Bereich Sicherheit sehr anspruchsvollen Kunden wie der CIA. Doch es scheint eine immer größere Lücke innerhalb des Unternehmens zu geben, die mehr Sicherheit auch für Java und JRE verhindert. Wenn JRE nicht eine zu große Gefahr für Unternehmen darstellen soll, muss sich das ändern.

Methoden zur Absicherung von Java

In den Augen vieler Sicherheitsexperten ist der Sicherheitsstatus von Java so unbefriedigend, dass es auf allen Client-Anwendungen von Unternehmen deaktiviert werden sollte. Doch während es für Software wie den Acrobat Reader durchaus gute Alternativen gibt, existiert Derartiges für das Java Runtime Environment zurzeit nicht. Viele Enterprise-Anwendungen brauchen Java, so dass die Deaktivierung schlicht nicht in Frage kommt.

Abgesehen davon gelten die üblichen Ratschläge für Sicherheit bei Client-Software auch für JRE. So sollte JRE nicht installiert (oder deinstalliert) werden, wenn es nicht wirklich gebraucht wird. Alte Versionen sollten entfernt werden, außerdem braucht es auf der Client-Seite Patch-Management und Endpunkt-Sicherheitsmaßnahmen. Allerdings sollte man über zusätzliche Schritte speziell für Java nachdenken. So ließen sich JRE und dafür nötige Software in einer eigenen virtuellen Maschine betreiben und JRE weniger Rechte geben (das sollte ohnehin der Standard sein); Java-Applets auf einer Whitelist könnten im JRE mit Noscript oder ähnlicher Software ausgeführt werden. Mit dem Enhanced Mitigation Experience Toolkit kann JRE auf Windows-Systemen sicherer konfiguriert werden.

Ebenso könnten Unternehmen Java-Code zu nativ ausführbaren Programmen kompilieren, um Probleme mit JRE zu umgehen. Doch damit würde der Java-Vorteil "einmal schreiben, überall ausführen" verloren gehen. Die meisten Java-Applets laufen auf PCs oder Macs. Insofern wäre der Zusatzaufwand für manche Organisationen wohl zu leisten, aber die Software läuft dann eben nicht mehr auf allen Plattformen, die Java unterstützt. Trotzdem würde eine solche Kompilierung die Zahl der Systeme in Unternehmen verringern, die etwa nur wegen einer einzigen Anwendung JRE installiert haben müssen. Dies bedeutet einigen Aufwand, doch das Risiko lässt sich für die meisten Unternehmen so auf ein akzeptables Niveau senken.

Schlussfolgerung

Das Java-Ökosystem war ein Pionier für viele neue Features, die die Softwareentwicklung für mehrere Plattformen leichter gemacht haben. Das Java Runtime Environment ist aus dem Wunsch nach einfacherer, Plattform-übergreifender Entwicklung hervorgegangen. Leider hat der Ruf des Java-Ökosystems durch die vielen Schwachstellen in JRE und im Software-Entwicklungszyklus von Oracle sehr gelitten. Organisationen sollten deshalb intensiv darüber nachdenken, ob sie sich auf Java festlegen wollen. Zum Glück lassen sich die JRE-Risiken auf  Endpunkten, die JRE geschäftlich brauchen, mit bestehenden Möglichkeiten eindämmen. Wenn JRE jedoch nicht unbedingt benötigt wird, sollte es auch nicht installiert werden.

Über den Autor:

Nick Lewis (CISSP) ist Architekt für Informationssicherheit an der Saint Louis University. Er hat einen Abschluss als Master of Science im Bereich Information Assurance von der Norwich University und in Telekommunikation von der Michigan State University. Vor seiner Tätigkeit für die Saint Louis University hat Lewis an der University of Michigan und am Children's Hospital Boston gearbeitet, außerdem für Internet2 und die Michigan State University.

Artikel wurde zuletzt im Dezember 2012 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Anwendungsangriffe (Cross-Site Scripting, Buffer Overflows)

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close