So will Oracle für mehr Sicherheit bei Java sorgen

Oracle hat nun die Schritte bekannt gegeben, die es unternehmen will, um die Sicherheit von Java vor allem für Firmen zu erhöhen. Dazu gehören eine zentrale Richtlinienverwaltung und die Möglichkeit, weiße Listen vertrauenswürdiger Applets zu erstellen. Beide Schritte sollen die Gefahr reduzieren, die von potenziellen Java-Schwachstellen in Desktop-Umgebungen ausgeht, und die Möglichkeiten einschränken, diese Schwachstellen auszunutzen, schreibt Oracle-Sprecher Nandini Ramani in einem Blogbeitrag.

Der Bekämpfung von Schwachstellen dienen laut Ramani neue Werkzeuge, die durch Quelltextanalyse bestimmte Arten von Anfälligkeiten ermitteln. Ramani weist auch darauf in, dass die Java-Entwicklungsabteilung seit der Übernahme von Sun durch Oracle im Jahr 2010 “die Produktion von Security-Fixes deutlich beschleunigt” habe. Den Zeitplan für Patches werde man bis Oktober noch einmal verdichten, wie Oracle dies auch bei anderen Produkten handhabe.

Für den Einsatz von Java in Firmen gibt es die genannten zwei wichtigen neuen Funktionen. Man reagiere damit auf “Bedenken bei Firmen, die Java-Anwendungen auf Servern einsetzen” – und trenne jetzt schärfer zwischen browserbasiertem sowie serverbasiertem Java. Mit Java 7 (Update 21) heißt die einschlägige Distribution “Server JRE” und umfasst kein Browser-Plug-in mehr. Auch Auto-Updates und der Installer fallen weg, die für die Heimanwender-Version typisch sind.

Firmen mit Java-Anwendungen können Java auf dem Client natürlich nicht abschalten. Doch hier gibt Oracle Administratoren mehr Kontrolle an die Hand. So sind weiße Listen vertrauenswürdiger Applets möglich, die sich zudem zentral verwalten lassen. Auch verringere man die Gefahr deutlich, dass sich Java-Malware von Desktops auf Server ausbreite, schreibt Ramani.

Kritik an der Java-Versionierung

Bereits vor einigen Tagen hatte Oracle angekündigt, Funktions-Updates künftig nur noch als Vielfache von zwanzig – also als 7u40, 7u60 etc zu versionieren. Dazwischen kommen die regelmäßigen Patch-Updates als Vielfaches von fünf, addiert auf die letzte generelle Update-Nummer und erhöht auf die nächsthöhere ungerade Zahl, falls sich eine gerade Zahl ergeben sollte – also nach dem Muster 7u25, 7u31 und 7u35. Ungeplante Patches erhalten die Nummern dazwischen – etwa 7u26, 7u27 etc.

“Insbesondere für das Management ist das momentane Schema schon schwer verständlich”, kritisierte Tobias Frech, stellvertretender Vorstandsvorsitzender des Interessenverbunds der Java User Groups e.V. (iJUG). “Das zukünftige wird noch komplizierter.”

Der iJUG fordert deshalb eine verständlichere Zählweise. Er schlägt vor, mit der Java-Version zu beginnen, gefolgt von den Funktions- und CPU-Updates und an dritter Stelle die Security-Updates, also zum Beispiel 7.1.3 für Java 7, erstes Funktions- und drittes Security-Update.

“Um die neue Zählweise schnellstmöglich umzusetzen würde es sich idealerweise anbieten, sie bereits mit Java 8 einzuführen”, wirbt Markus Eisele, Repräsentant der Deutschen Oracle-Anwendergruppe e.V. (DOAG) im iJUG. “Durch die Verschiebung des Release-Termins sollte dafür genügend Zeit vorhanden sein. Die Tests von Dritt-Software, die auf Java aufbaut, dürften deshalb noch nicht begonnen haben.”

[mit Material von Florian Kalenda, ZDNet.de]

Tipp: Wie sicher sind Sie bei der Sicherheit? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de.