Java fördert nun signierte Applets

Inhaltsverzeichnis

Java kommt seit einigen Monaten nicht aus der Schusslinie. Die Sicherheitslöcher haben nicht nur Fachmedien ausführlich behandelt, sondern wurden sogar von der Populärpresse zu vielen Endanwendern gebracht. Oracle reagiert konsequent, aber vergleichsweise lautlos. Am 16. April 2013 ist Java 7 Update 21 mit der bisher weitreichendsten Änderung erschienen. Die Sicherheitseinstellungen erlauben dann das lautlose Ausführen unsignierter Applets nicht mehr.

Java-Applets sind mitverantwortlich für den Erfolg von Java. Bewegung im Browser war zu den Anfangszeiten des Internet ein absolutes Novum. Der anfängliche Hype ist lange vorbei. Selbst der zwischenzeitliche Marktführer, Flash, ist in der Verbreitung rückläufig. Dennoch ist das "write once run everywhere"-Paradigma weiterhin eine Hauptmotivation für die Verwendung von Java-Applets – allerdings nicht mehr im Multimedia-Bereich, sondern viel mehr im Umfeld professioneller Anwendungen.

Hier findet man hauptsächlich zwei Anwendungsfälle: die Anbindung spezieller Endgeräte wie Kartenleser und die Verteilung von Java-Clients im Web. Während Letzteres zunehmend eine Altlast in großen Unternehmen darstellt, sind die Client- und plattformunabhängige Anbindung von Hardware und auch die verschlüsselte Übertragung mit Zertifikaten brandaktuelle Anforderungen vieler Online-Angebote von Behörden. In Deutschland ist ein prominentes Beispiel das Elster-Steuerportal. Wer eine Steuererklärung machen will oder muss, ist zwangsläufig auf Java angewiesen. In anderen Ländern ist das nicht viel anders. Die hilflosen Empfehlungen, Java komplett vom Rechner zu entfernen, sind somit nur auf den ersten Blick eine Lösung. Die verschreckte Reaktion, die irgendwann einmal installierte Version gar nicht mehr anzufassen oder gar zu aktualisieren, stellt ein großes Sicherheitsrisiko dar. Die klare Empfehlung lautet also, die Java Runtime immer auf der aktuellen Version zu verwenden und die verfügbaren Sicherheitseinstellungen geeignet vorzunehmen.

Sicherheit einstellen

Mit dem Java 7 Update 10 wurden die nutzerspezifischen Sicherheitseinstellungen erstmalig ausgerollt. Damit war es möglich, nur Anwendungen auszuführen, deren Code mit dem Zertifikat von einer gültigen und vertrauenswürdigen Stelle (CA) signiert wurden. Mit Update 17 erweiterte Oracle das Java Control Panel um einen einfach zu bedienenden Schieberegler zur Einstellung des Sicherheitslevels nicht signierter Applets. Es lässt sich zwischen den Einstellungen niedrig, mittel, hoch und sehr hoch auswählen. Je niedriger die Sicherheitseinstellung, desto weniger Warnungen werden dem Anwender im Browser angezeigt. Er versteht sich also nicht als Einschränkung bezüglich der Fähigkeiten von Java im Browser generell, sondern hat lediglich Einfluss auf die Anzahl der Meldungen im Browser. Das ermöglicht den Endanwendern die schnelle und komfortable Einstellung der Sicherheitsmeldungen. Dieses Update hatte keinen Einfluss auf die bisherigen Anwendungen. Mit dem nun verfügbaren Update 21 ändert sich das. Oracle hat Anfang des Jahres angekündigt, dass sich das Verhalten des Browser-Plug-ins beim Umgang mit unsigniertem Code ändern wird.

Was sich lange Zeit schwammig angehört hatte und nur wenige in den konkreten Auswirkungen bewerten konnten, ist nun bekannt. Tatsächlich ändert sich die Möglichkeit zur Sicherheitseinstellung im Java Control Panel. Der Level "niedrig" steht nicht mehr zur Verfügung. Für Java im Browser bedeutet das, dass das Ausführen unsignierter Applets nicht mehr ohne Warnung für den Endanwender möglich ist. Im Rahmen der Änderung werden auch die Meldungen der Java Runtime beim Ausführen eingebetteter Inhalte präziser.

Was bedeutet das nun konkret?

Die Änderungen lassen sich am besten anhand von ein paar Beispielen illustrieren. Zu diesem Zweck wird ein einfaches Swing-Applet verwendet. Die Klasse public class AppletDemo extends Japplet überschreibt die init()-Methode und erstellt einen neuen GUI-Thread, der auf dem Container ein JLabel mit dem Text "You are successfully running a Swing applet!" hinzufügt. Neben der Java-Klasse gehört noch eine HTML-Seite dazu. Dabei gibt es diverse Möglichkeiten, Java-Applets in den Browser einzubetten. Die älteste ist die Variante unter Verwendung des <applet>-Tags. Er wurde mit HTML 4.1 als "deprecated" gekennzeichnet und lässt sich in HTML5 nicht mehr verwenden. An seine Stelle tritt der <object>-Tag. In HTML5 ist darüber hinaus der <embed>-Tag hinzugekommen. Um sich nicht mit den browserspezifischen Details herumärgern zu müssen, stellt Java das sogenannte Deployment Toolkit zur Verfügung. Das ermöglicht eine einfache und browserübergreifende Einbindung mit ein paar Zeilen JavaScript:

<script src="http://www.java.com/js/deployJava.js"></script>
            <script>
                var attributes = {
                    code:'appletdemo.AppletDemo.class', width: 300, 
                         height: 300};
                var parameters = {jnlp_href: 'applet_demo.jnlp'};
                deployJava.runApplet(attributes, parameters, '1.6');
            </script>

Für einen Entwickler sind die Schritte durchaus bekannt. Neben dem gezeigten Beispiel kann der JNLP-Mechanismus (Java Network Launching Protocol) auch Java-WebStart- oder JavaFX-Applikationen starten. Über die zugehörige Konfigurationsdatei (siehe die Sourcen) lassen sich zusätzliche Einstellungen wie Berechtigungen oder plattformspezifische Abhängigkeiten vornehmen. Egal auf welche Art das Java-Plug-in in die Webseite eingebunden und in welchem Browser diese dann läuft, wird der Code in einer sogenannten Sandbox ausgeführt. Die Fähigkeiten oder besser Berechtigungen für nicht signierten Sourcecode steuert der bekannte Java-Sicherheitsmechanismus mit policy-Dateien. Neben den globalen $JRE_HOME/lib/security/java.policy und $USER_HOME/.java.policy lassen sich für den Browser noch zwei weitere angeben. Das geschieht indirekt über eine Datei mit dem Namen deployment.properties (Details dazu finden sich hier). Diese Rechte definieren die Möglichkeiten, welche unsigniertem Code in der Sandbox zur Verfügung stehen.

Wer also aus einem unsignierten Applet heraus auf lokale Ressourcen wie das Dateisystem zugreifen möchte, wird mit einem unsignierten Applet schnell in einen entsprechenden Ausnahmefehler laufen. Der Versuch, ein neues File in d:\temp zu schreiben:

Path target = Paths.get("D:\\temp\\test.txt");
                    try {
                        Path file = Files.createFile(target);
                        created = true;
                    } catch (IOException ex) {
                        System.err.println("Creating file failed");
                        ex.printStackTrace(System.err);
                    }

führt beispielsweise zu:

java.security.AccessControlException: access denied
        ("java.io.FilePermission" "D:\temp\test.txt" "write")

Nicht einfach nur lästig, sondern funktionsverhindernd. Aber genau das soll ja die Sandbox ermöglichen: eine eingeschränkte und sichere Ausführungsumgebung, in der sich nicht auf böswillige Art auf bestimmte Informationen auf dem Client zugreifen lässt.

Anwender- und Entwicklersicht

Die Sicht des Anwenders

Der Anwender bekommt übrigens bis hier nur wenig von den beschriebenen Aktivitäten mit. Startet er die bereitgestellte Webseite über seinen Browser, weist dieser ihn lediglich einmal grundsätzlich auf den aktiven Inhalt hin (siehe Beispiel-Screenshots IE und Chrome). Das geschieht aber allein aufgrund der Tatsache, dass es sich um ein Java-Applet handelt, und ist abhängig von der gewählten Sicherheitseinstellung im Browser. Hier spielt weder das oben genannte Java Control Panel noch eine andere Sicherheitseinstellung von Java eine Rolle.

Bestätigt der Anwender nun, dass er Java wirklich ausführen will, startet das Browser-Plug-in die Java Virtual Maschine und führt die Anwendung aus. Erst hier folgt die erste Hinweismeldung von Java (s. Abb. 4)

Dabei sind die Meldungen von Java im Browser vielfältig in Form und Farbe und doch alle sehr ähnlich aufgebaut. In Abhängigkeit des durch Oracle eingeschätzten Risiko-Levels werden die Meldungen, die auf weniger risikoreiche Anwendungen hinweisen, mit dem Java-Logo oder einem blauen Schild mit einem "i" (für Information) darin dargestellt (Abb. 5).

Meldungen mit einem gelb hinterlegten Ausrufezeichen (Schild oder Dreieck, vgl. Abb. 4) informieren den Anwender über ein entsprechend höheres Risiko. Das gelbe Dreieck erscheint bei nicht vertrauenswürdigen oder abgelaufenen Zertifikaten, das Schild bei unsignierten Anwendungen oder bei Anwendungen mit ungültigem Zertifikat. Bisher gab es also nur ein einheitliches Gelb für alle Dialoge, die auf nicht signierte Inhalte hingewiesen haben. Die Interpretation der textuellen Details oder auch den Unterschied zwischen Schild und Dreieck mussten sich die Anwender irgendwann aneignen. Viele kennen den Unterschied vermutlich bis heute nicht. Mit dem nun vorliegenden Java 7 Update 21 werden diese Dialoge ein wenig konkreter. Bei bestimmten Kombinationen erscheint ein zusätzlicher Text in roter Schrift. Die neue Kennzeichnung bestimmt die Kombination der folgenden Attribute:

• signierte beziehungsweise nicht signierte Anwendung
• nicht vertrauenswürdiges, abgelaufenes oder ungültiges Zertifikat
• Anwendung erfordert Sandbox oder volle Berechtigung

Zukünftig hat beispielsweise die Java-Bestätigungsmeldung für eine nicht signierte Anwendung einen zusätzlichen in Rot dargestellten Text, und Oracle weist auf einer separaten Webseite darauf hin, dass diese Art von Anwendungen besser nicht ausgeführt werden soll.

Das blaue, vertrauenswürdige Ausrufezeichen und das Java-Logo werden nur noch bei Anwendungen angezeigt, die mit einem gültigen Zertifikat von einer vertrauten CA signiert wurden. Eine vollständige Auflistung der Kombinationen und der dazugehörigen Anzeigen findet sich auf der Webseite von Oracle.

Hintergrund für den Entwickler

Für den Entwickler bedeuten die Änderungen erst einmal, dass die Mehrzahl der Endanwender die Sicherheitsstufe nicht mehr auf "niedrig" oder individuell einstellen kann. Daraus resultiert, dass es nicht mehr so einfach ungewollt zum Ausführen nicht signierter Java-Anwendungen im Browser kommen kann. Auch wenn sich die dem Schieberegler entsprechenden Einstellungen in den "Erweiterten Einstellungen" des Java Control Panel durchaus noch vornehmen lassen, ändert sich an den Anwendungen selbst nichts. Allerdings ist es nun dringend zu empfehlen, Java-Anwendungen, die im Browser laufen sollen, mit einem gültigen Zertifikat zu signieren, wenn man ohne die neuen Warnungen auskommen will oder muss. Der grundsätzliche Prozess funktioniert einfach. Alles beginnt mit einem RSA-Schlüssel-Paar. Das lässt sich auf unterschiedliche Weise erstellen. Am einfachsten geht es mit dem Keytool aus Java.

keytool -genkey -keyalg rsa -alias HeiseDemo

Nach dem Ausführen wird man nach einer Handvoll Angaben gefragt. Diese beantwortet man entsprechend. Im Beispiel wird ein neues Schlüsselpaar mit den folgenden Attributen erzeugt:

CN=Markus Eisele, OU=Developer Channel, O=heise.de, L=Hannover, 
       ST=Niedersachsen, C=DE 

Für das Schlüsselpaar ist noch ein Passwort zu vergeben. Das geschieht ebenfalls durch das Keytool. Das Schlüsselpaar wird im Java Keystore abgelegt. Nun ist die eigentliche Zertifikatssignaturanfrage (Certificate Signing Request) zu generieren (PKCS#10). Das geschieht mit dem Befehl:

keytool -certreq -alias HeiseDemo -file myapplet.csr

Diese Aktion ist erneut mit dem Keystore-Passwort zu bestätigen. Typischerweise wird der Inhalt des Zertifikat-Requests an eine Certificate Authority (CA) gesendet. Der große Unterschied liegt hierbei in der Art der CA. Nur die 79 öffentlichen CAs, die im Keystore von Java bekannt sind, bringen den gewünschten Effekt. Oracle hat einen separaten Prozess, über den Firmen ihre Root CAs in die JVM bringen können. Für Endanwender oder große Firmen ist das kaum eine Option, da die Anforderungen umfänglich sind. Da bleibt zumeist nur der Rückgriff auf eine der bekannteren, öffentlichen CAs. Die verlangen allerdings Geld für ihre Dienstleistungen.

Die gewählte CA signiert den Request und schickt ein "PKCS#7 Public Key"-Zertifikat (bspw. cert.p7c) zurück. Es wurde von der öffentlichen Root CA signiert und lässt sich damit von der Java Runtime (JVM) validieren. Dieses ist nun ebenfalls in den Keystore zu importieren:

keytool -import -alias HeiseDemo -trustcacerts -file cert.p7c

Nach erneuter Eingabe des Keystore-Passworts steht das Zertifikat zum Signieren des Applets zur Verfügung. Das übernimmt ein weiteres JDK-Werkzeug:

jarsigner -verbose -signedjar AppletDemo.jar unsigned_Applet.jar HeiseDemo

Nach der obligatorischen Eingabe des Keystore-Passworts erscheint die Log-Ausgabe, die die konkreten Änderungen in der Jar-Datei ausgibt:

updating: META-INF/MANIFEST.MF
   adding: META-INF/MYAPPLET.SF
   adding: META-INF/MYAPPLET.RSA
   adding: appletdemo/
  signing: appletdemo/AppletDemo$1.class
  signing: appletdemo/AppletDemo.class

Damit ist das Applet signiert und wird ohne Probleme vom Browser ausgeführt. Darüber hinaus ist der Browser-Dialog von Java nun blau hinterlegt (vgl. Abb. 5) und suggeriert dem Endanwender eine deutlich höhere Vertrauenswürdigkeit.

Fazit

Oracle verbessert die Sicherheit des Browser-Plug-ins ständig. Das scheint ein Indikator dafür zu sein, dass der Java-Statthalter mit dem Status quo selbst nicht zufrieden ist. Auf diversen Konferenzen der vergangenen Wochen hat der für die Sicherheit der Java-SE-Plattform verantwortliche Milton Smith über den aktuellen Stand der Bemühungen informiert. Und auch die JavaOne wird einen separaten Security Track beherbergen. Tatsächlich können die Java-Anwender mit der aktuellen Situation noch nicht zufrieden sein. Auch wenn Oracle sich offensichtlich bemüht, besser und offener zu kommunizieren, bleibt die Informationslage noch immer undurchsichtig. Bis zu einem gewissen Grad mag das bei einem so sensiblen Thema richtig sein, dennoch bleibt der Wunsch nach einer weiteren Verbesserung und deutlich früheren Informationen zur Gefahrenlage.

Es bleibt festzustellen, dass Java im Browser grundsätzlich nicht gefährlicher oder sicherer ist als andere Plug-in-Ansätze. Aufgrund der starken Verbreitung ist es allerdings nach wie vor eines der Top-Angriffsziele für Hacker. Somit sind die kommenden Änderungen eine Verbesserung für den Endanwender. Um sicherzustellen, dass diese auch alle erreichen, wäre es wünschenswert, wenn deutlich häufiger und schneller auf neue Versionen umgestellt wird.

Markus Eisele
ist Principal IT Architect bei der msg systems AG in München und Mitglied der Java EE 7 Expert Group und der iJUG.

Onlinequellen

• Signing Applets Using RSA Certifcates
• Browser Security Messages

(ane)