14 Java-Sicherheit

Fügen wir an dieser Stelle einen kleinen Break bezüglich der konkreten Programmierung ein und wenden uns einem wichtigen Hintergrundthema zu. Das Thema Sicherheit und Java gehören eng zusammen. Nicht zuletzt, weil es auch um das Internet als offenes Netzwerk geht.

Bis vor einiger Zeit wurde die Sicherheit von Computern mit dem Verhindern von Daten-Crashs und der Abwehr von Computerviren gleichgesetzt. In geschlossenen Netzwerken galt zusätzlich der Abwehr von unbefugten Eindringlingen das Augenmerk. Das Internet selbst war offen und barg außer diesen Risiken keine Gefahren. Zumindest solange das auf dem HTTP-Protokoll basierende HTML die einzige Sprache des WWW war. Da man nur mithilfe eines Browsers (Telnet, FTP & Co. mal außen vor) Daten von einem Server abrufen konnte und echte Interaktivität kaum stattfand, konnte auch außerhalb des Browsers - sprich im restlichen Computersystem - nicht viel unbemerkt passieren. Dies hat sich mit dem Auftauchen von ActiveX, aber auch mit Java geändert.

Es gehört jedoch zu den zentralen Argumenten für Java, dass dort dieses Thema Sicherheit ganz groß geschrieben wird. Dennoch darf man nicht in unkritische Euphorie verfallen, nur weil Java gegenüber der Konkurrenz eine neue Welt der Sicherheitsaspekte geöffnet hat und Programmierern eine bisher kaum gekannte Möglichkeit eröffnet, sicher ausgelegte Programme zu entwickeln. Immerhin ist in der Vergangenheit mehrfach gezeigt worden, dass auch Java nicht ganz frei von Sicherheitslücken war.

Dennoch - das Konzept von Java ist durch und durch auf Sicherheit ausgelegt, was auch die zahlreichen auf Java basierenden Anwendungen im Bereich Online-Banking über Internet und bei verwandten Vorgängen zeigen.

14.1 Das Java-Sicherheitskonzept

Es gibt viele Aspekte, die bei einem schlüssigen Sicherheitskonzept zu berücksichtigen sind. Statt alle erdenklichen Angriffsszenarien abzudecken, postuliert Javas Sicherheitsmodell potenzielle Ziele, die Angriffen bzw. Angriffskategorien ausgesetzt sind. Insbesondere schützt das Sicherheitsmodell von Java den Hauptspeicher, den Festplattenspeicher eines Clients, das Betriebssystem und den Programmzustand sowie das Netzwerk vor Angriffen folgender Art:

Javas Sicherheitsmechanismen greifen - rein auf das Sprachkonzept bezogen - auf vier Ebenen des Computersystems. Die erste Ebene ist die der Sprache an sich und der zugehörige Compiler samt kompilierter Klassen. Die zweite Ebene betrifft die Verifizierung des Bytecodes zur Laufzeit. Dort wird im Wesentlichen darauf geachtet, dass zentrale Sicherheitsregeln eingehalten werden. Ebene drei ist der Classloader, der Klassen beim Laden analysiert und nach verschiedenen Kriterien mit Rechten versieht. Außerdem lässt er nur »freundliche« Klassen passieren. Die letzte Ebene ist ein so genannter SecurityManager, der als abstrakte Java-Klasse zur Laufzeit zerstörerische Verhaltensweisen von Java-Programmen verhindert.

14.1.1 Die Missbrauchsfähigkeiten einer Sprache

Ein wichtiger Ansatzpunkt für die Sicherheit eines Systems sind sprachspezifische Sicherheitslücken durch diverse Zugriffsmöglichkeiten auf lokale Rechnerressourcen. Die C/C++-Sprachmöglichkeiten sind das wichtigste Beispiel für diese Missbrauchsfähigkeiten (bewusst und unbewusst durch nicht mehr kontrollierbare Fehlerquellen) einer Programmiersprache in einer weitgehend ungeschützten Umgebung. Grundsätzlich muss man festhalten, dass der Verzicht von Java auf C/C++-typische und sehr maschinennahe Sprachelemente wie Pointer, Zeigerarithmetik, ungeprüfte Typumwandlung, die Speicherallokation und die anschließende Freigabe über free() - Java nutzt statt dessen mit der Garbage Collection ein konservatives Mark/Sweep-Verfahren - ein erhebliches Maß an Sicherheit gebracht hat. Zum einen sind Java-Programme erheblich stabiler als vergleichbare C/C++-Programme (ein nicht zu verachtender Aspekt), zum anderen ist die Sprache vieler sprachspezifischer Missbrauchsfähigkeiten beraubt. Gerade die Unterbindung von direkten Zugriffen auf Objekte vermeidet erhebliche Bedrohungen. Ganz herheblich tragen die sprachintegrierten Exceptions zur Stabilität von Java bei. Sie ermöglichen in Java definierte und kontrollierte Programmabbrüche.

Im Detail sind folgende Aspekte des Java-Designs auf maximale Sicherheit ausgelegt:

Strikte Objektorientiertheit

Java ist strikt objektorientiert, da jede einzelne Datenstruktur (und aus ihr abgeleitete Datenstrukturen) ein vollkommen eigenständiges Objekt erster Klasse darstellt. Das ist nicht nur unter dem Aspekt der Programmierung ein wichtiges Detail, sondern auch aus Sicherheitsgründen. Damit ist sichergestellt, dass in Java alle theoretischen Sicherheitsvorteile der objektorientierten Programmierung (OOP) sowohl in der Syntax als auch in der Semantik bei Programmen wiederzufinden sind. Dies meint im Wesentlichen das Verstecken von Daten hinter privaten Deklarationen. Auf diese darf man entweder gar nicht oder nur über öffentliche Methoden zugreifen, die dann eine gezielte Filterung erlauben. Diese Datenkapselung können wir mit einem kleinen Beispiel demonstrieren.

Das Beispiel soll eine Geschwindigkeitsänderung eines Autos (sehr vereinfacht) demonstrieren. Die Geschwindigkeit (tempo) ist in der Klasse PrivateVar als private deklariert. Nach außen wird nur eine Methode tempoAendern() bekannt gegeben, die widerum aber diese Variable nutzt. Wenn nun aus der zweiten Klasse Speed heraus diese private Information genutzt werden soll, kann das nur über die filternde Methode erfolgen, nicht direkt.

class PrivateVar {
private int tempo=200;
int tempoAendern(int gesch) {
System.out.println(
  "Gewuenschte Geschwindigkeit: "+gesch);
if(gesch>tempo) {
System.out.println("Motor wird abgeriegelt");
gesch=200;
}
return(gesch);
}  }
Private Variable und öffentliche Methode, die die Variable nutzt
class Speed {
public static void main(String args[]) {
PrivateVar a = new PrivateVar();
/* a.tempo = 300;
System.out.println("Geschwindigkeit: " + a.tempo); 
*/
System.out.println("Max: " + a.tempoAendern(300));
System.out.println("Max: " + a.tempoAendern(199));
}  }

Der Zugriff funktioniert nur so wie in dem nicht auskommentierten Teil demonstriert.

Abbildung 14.1:  So funktioniert  der Zugriff

Wenn Sie den auskommentierten Teil aktivieren, wird der Compiler den Zugriff nicht gestatten.

Abbildung 14.2:  Der Compiler erlaubt keinen direkten Zugriff auf private Informationen von außen.

Die strenge Einhaltung von diesen Zugriffsleveln bedeuten die Unterbindung von nicht gewünschen Zugriffen auf Datenstrukturen.

Finale Klassen, Variablen und Methoden

In Java können Klassen, Variablen und Methoden bekanntlich als final deklariert werden, womit eine weitere Ableitung der Klasse, das Verändern von Variablenwerten und das Überschreiben von Methoden nicht mehr möglich ist. Dementsprechend kann bereits überprüfter Code nicht böswillig verändert werden.

Strenge Typisierung und sichere Typumwandlung

Java ist streng typisiert. Die Typumwandlung wird in Java sowohl statisch als auch dynamisch geprüft, um sicherzustellen, dass der deklarierte Kompilierzeit-Typ eines Objekts mit einem eventuellen Laufzeit-Typen kompatibel ist, selbst wenn das Objekt in einen anderen Typ umgewandelt wird.

Keine Pointer

Dies ist wahrscheinlich der beste Garant für Sicherheit in Java. Da Java keine Pointer (zumindest nicht im Sinne von C/C++) verwendet, sondern Objektreferenzen, werden sämtliche Umwandlungen und Zugriffe vorab (d.h. vor der eigentlichen Laufzeit) bereits auf Zulässigkeit geprüft. Das Ausschließen von direkten Zeigern stellt immer sicher, dass kein Teil eines Java-Progamms jemals anonym ist. Der Zugriff auf jede einzelne Datenstruktur und auf jedes Code-Fragment kann zurückverfolgt werden. Die statt Pointern verwendeten Array-Strukturen in Java gleichen nicht nur das Fehlen der Pointer aus, sondern steigern die Sicherheit, indem die Grenzen eines Arrays strikt festgelegt sind. Zudem ist jedem einzelnen Java-Objekt ist Hash-Code (Kontrollcode) zugeordnet. Das bedeutet, dass der Status eines Java-Programms jederzeit aufgezeichnet werden kann. Damit sind aber nicht nur unbewusste Fehler vermieden, ebenfalls sind die Missbrauchsfähigkeiten eingeschränkt bzw. leichter erkennbar.

Thread-sichere Datenstrukturen

Java ist Multithreading-fähig. Dies erzwingt in Bezug auf Sicherheit und Stabilität einen Thread-sicheren Zugriff auf Datenstrukturen und Objekte. Java besitzt einen solchen, der viel zur allgemeinen Stabilität des Systems beiträgt.

Sicherer Ansatz des Methoden- und Variablen-Aufrufs

Java verwendet einen besonderen Ansatz, um Funktionen aufzurufen. Normalerweise rufen PC-Programme Funktionen über eine numerische Adresse auf. Da diese Adresse eine numerische Folge ist und diese Folge vom Programmierer beliebig programmiert werden kann, kann eine beliebige Zahl genommen werden, um dem Programm zu sagen, wie es eine Funktion ausführen soll. Damit wird eine Anonymität aufrecht erhalten, mit der es unmöglich ist herauszufinden, welche Funktionen bei der Programmausführung tatsächlich verwendet werden. Java seinerseits verwendet Namen zum Aufruf von Methoden und Variablen. Auf Methoden und Variablen kann allein mit dem Namen zugegriffen werden. Zu bestimmen, welche Methode und Variablen verwendet werden, ist also einfach. Diese Verifizierung wird dazu verwendet, sicherzustellen, dass der Bytecode nicht beschädigt oder verändert wurde und die Anforderungen von Java als Sprache erfüllt.

Zusammenfassend kann man festhalten, dass Java also auf der Sprach- und Compilerebene bereits extrem sicher ist.

14.1.2 Viren

Viren innerhalb von Fremdsoftware sind ein Aspekt, gegen den bisher kaum schlüssige Konzepte auf der Ebene der Programmiersprachen und Entwicklungsumgebungen präsentiert wurden. Seit Jahren empfehlen Experten dringend, jedes fremde Programm und jeden fremden Datenträger auf Viren zu überprüfen, bevor man damit arbeitet. Und im Internet verfuhr man in der Vergangenheit oft so, als befände man sich in Fort Knox. Java bietet nun auf Sprachebene diverse Kontrollmöglichkeiten gegen Viren im Javacode und überprüft defaultmäßig den Bytecode. Wie diese Kontrolle im Detail funktioniert, kann am besten in Zusammenhang mit unkontrollierten Zugriffen auf Systemressourcen erklärt werden.

14.1.3 Unkontrollierte Systemzugriffe

Eine ähnliche Gefahr wie Viren sind unkontrollierte Festplattenzugriffe (Löschen oder Verändern von Dateien, Formatieren von Datenträgern) und sonstige Zugriffe auf Systemressourcen. Zwar ist die konkrete Thematik hier noch komplexer als bei Viren, die Logik ist allerdings identisch. Auch im Falle von Java-Applets (oder vor allem ActiveX-Controls) werden Objekte auf dem lokalen Rechner abgelegt, deren genaue Funktionalität nicht immer vollständig klar ist. Microsofts ActiveX-Technologie wird von vielen Experten als das derzeit größte Sicherheitsrisiko der EDV-Welt angesehen. Wer sagt denn, dass das nette ActiveX-Control nur ein harmloses Spiel ist und die permanenten Festplattenzugriffe ausschließlich Spielstände abspeichern? Man muss sich immer darüber im Klaren sein, dass es sich bei jedem dieser Objekte um eine Art lauffähige Programm handelt, das durchaus ein anonymes (schädliches) Doppelleben führen kann. Wenn im Detail unbekannte Objekte Schreiboperationen auf der Festplatte ausführen wollen, sollten Alarmglocken klingeln. Bei aller Euphorie über Java-Applets und sonstiger toller Internetanimationen darf man nicht vergessen, dass über das Netz (oder ggf. von lokalen Datenträgern) fremde Anwendungen auf den Rechner gelangen, denen man erst einmal ein gesundes Misstrauen entgegenbringen sollte. Java stellt da mit seinem Sicherheitskonzept einen Meilenstein dar.

Bei Java-Applets können unkontrollierte Festplattenzugriffe - sogar von vollkommen unbekannten Applets - einigermaßen beherrscht werden. Verantwortlich dafür ist im Wesentlichen der Container (also der Browser oder der Appletviewer). Dieser analysiert mithilfe des Applet-Classloaders bereits beim Laden aus dem Netz den Applet-Code unter anderem auf Viren und Festplattenzugriffe oder andere unerlaubte Befehle. Damit wird bereits eine Pforte aufgebaut, die viele subversive Klassen erst gar nicht überwinden können. Und falls doch, unterbindet der Container - je nach internen Einstellungen - diese Zugriffe mithilfe eines permanent laufenden Hintergrundprozesses. Selbst wenn es also ein »schlechtes« Applet geschafft hätte, den umfangreichen Verifzierungsprozess von Java zu umgehen, wäre der Schaden, den es anrichten könnte, doch ziemlich begrenzt, da Java-Applets nur in einer eingeschränkten Umgebung - dem so genannten Sandkasten (Sandbox) - ausgeführt werden und dort Restriktionen zu setzen sind. Sie können sich ja bei der Sicherheitseinstellung des Appletviewers oder eines Browsers ansehen, welche Einstellungen dort möglich sind. Innerhalb dieser Containerumgebung hat ein Java-Applet normalerweisee nicht die Erlaubnis, bestimmte gefährliche Funktionen auszuführen, es sei denn, der Endanwender gibt explizit seine Erlaubnis. Aber wie erfolgt genau die Verifizierung des Bytecodes?

14.1.4 Verifizierung des Bytecodes

Vor der Ausführung einer Applikation durch einen Browser oder den Appletviewer bzw. den Java-Interpreter wird jeder Bytecode diversen Tests unterzogen. Es wird beispielsweise überprüft, dass keine Zugriffsbeschränkungen verletzt werden, dass Methoden keine unzulässigen Argumente enthalten oder dass der Stack nicht überläuft.

Typinformationen und Anforderungen

Einen wesentlichen Anteil an der Verifizierung des Bytecodes bilden die Informationen über Typen. Java-Bytecode enthält mehr Typinformationen als der Interpreter eigentlich benötigt, beispielsweise Symboltabellen. Dadurch kann zur Laufzeit sichergestellt werden, dass Java-Objekte und -Daten nicht unbemerkt manipuliert werden.

Vor und nach der Ausführung eines Java-Programms hat jeder Wert in dem Stackbereich und jede Variable einen bestimmten Typ. Man nennt dies den Typzustand der Ausführungsumgebung. Dieser Typzustand ist statistisch zu überwachen und kann dafür verwendet werden, Pfadangaben und Verzweigungen eines Programms zu verfolgen. Außerdem kann mithilfe der zusätzlichen Typeninformationen ein spezieller Java-Mechanismus aktiv werden, der Verifier genannt wird.

14.1.5 Der Verifier

Der Bytecode-Verifier gehört zur Laufzeitumgebung von Java, also der JVM. Man kann ihn sich als ersten Grenzposten für eine fertige Klasse vorstellen, welchen die Klasse passieren muss, um überhaupt erst in die Laufzeitumgebung zu gelangen. Nur eine Klasse, die sich bzgl. wichtiger Aktionen als unbedenklich ausweisen kann, darf diese äußere Grenze der Laufzeitumgebung überschreiten. Anhand der zusätzlichen Typeninformationen in jeder .class-Datei überprüft der Bytecode-Verifier den vollständigen Bytecode und kontrolliert die Typen hinsichtlich aller Parameter, Namensraumkonflikte, Argumente und Ergebnisse. Damit kann man garantieren, dass Bytecode, der vom Verifier nicht moniert wurde, auf keinen Fall Stack-Overflows (sowohl nach oben als auch nach unten) erzeugen, ungültige Registerzugriffe ausführen, falsche Parameter, Argumente oder Returnwerte verwenden oder ungültige Konvertierungen von Daten und Typen sowie illegale Zugriffe auf Objektfelder erzeugen. Letzteres bedeutet, dass der Bytecode-Verifier auf strikte Einhaltung von public, private, package und protected bei Methoden und Variablen prüft. Der Verifier trägt also ebenfalls viel zu einer - rein technischen - Sicherheit von Java bei.

14.1.6 Der Classloader

Etwas höher als der Verifier ist der so genannte Classloader (Klassenlader) als ein weiterer Grenzposten gegen unbefugte Sicherheitsverletzungen aufgebaut. Wenn eine neue Klasse in ein System geladen wird, muss sie auch diesen Grenzposten passieren. Je nachdem, von wo die neue Klasse in das System geladen wird, wird sie vom Classloader unterschiedlich behandelt.

Standardmäßig gibt es drei unterschiedliche Szenarien, von wo eine neue Klasse geladen werden kann:

1. Aus dem Internet
2. Aus einem per Firewall geschützten lokalen Netzwerk
3. Vom lokalen Rechner selbst

Denkbar sind jedoch beliebig viele Szenarien. Beim lokalen Laden (die Definition von lokal war bis zum JDK 1.1 mit dem CLASSPATH verbunden, worauf nachfolgend noch eingegangen wird) von der Festplatte lädt und überprüft übrigens defaultmäßig nicht mehr der Applet-Classloader, sondern der File-Loader des Dateisystems, was unter Umständen ein erhebliches Sicherheitsrisiko sein kann. Prinzipiell sind Applets größere Sicherheitsrisiken als eigenständige Applikationen. Wenn ein fremdes Applet über Diskette oder CD auf den Rechner und dort in scheinbar sichere Verzeichnisse, d.h. Verzeichnisse innerhalb der ursprünglichen CLASSPATH-Angabe bzw. in den als sicher empfundenen Suchpfad des SDK 2 gelangt, wird es nicht mehr so intensiv überprüft.

Ein solches Applet sollte sehr vertrauenswürdig sein, denn es hat damit meist einige Rechte, die der Applet-Loader sonst nicht gestatten würde. Beispielsweise können diese Applets - bei entsprechender Einstellung - von der lokalen Festplatte lesen und auf diese schreiben, Bibliotheken auf dem Client laden, externe Programme auf dem lokalen Rechner ausführen, sich der Überprüfung des Bytecode-Verifiers entziehen und sogar im Prinzip die virtuelle Maschine von Java verlassen.

Der Classloader unterbindet auf jeden Fall das Ersetzen einer Klasse in einem höher priorisierten Bereich (etwa in einem per Firewall geschützten lokalen Netzwerk) durch eine Klasse aus einem niedriger priorisierten Bereich (etwa aus dem Internet). Insbesondere lässt der Classloader nicht zu, dass eine Klasse auf dem lokalen System durch eine Klasse von »außen« unbemerkt ersetzt wird. Zudem unterbindet der Classloader einen Aufruf von Methoden einer höher priorisierten Klasse durch Klassen aus einem niedriger priorisierten Bereich, es sei denn, diese Klassen sind explizit als public deklariert. Und last but not least unterbindet der Classloader ein Aufruf von Methoden eines Applets durch ein anderes Applet, es sei denn, dieses erlaubt es ausdrücklich. Dahinter steckt eine Technik, die Applets der gleichen Quelle (Host oder lokaler Rechner) in einem »Namespace«-Paket zusammenfasst. Damit teilt der Classloader die Welt der Applets in kleine Gruppen auf, denen von vornherein unterschiedliche Sicherheitsrisiken zugeordnet werden. Als Defaultwert überprüft der Classloader nur solche Klassen, die von außen (also von einem Host, einem lokalen Netzwerk oder auch einem Verzeichnis außerhalb des sicheren lokalen Pfads) kommen. Die getrennten Namensräume sind die Begründung, warum es wie oben beschrieben nicht möglich ist, Klassen auszublenden und durch manipulierte Klassen von außerhalb zu ersetzen. Wird eine Klasse benötigt, sucht der Classloader immer zuerst innerhalb des eigenen lokalen Namenraums und dann erst in weiteren Namensräumen. Damit haben lokal installierte Klassen immer Vorrang gegenüber den Klassen, die aus einem Netzwerk bezogen werden. Dieser Vorgang setzt sich nach der Priorität nach unten fort.

14.1.7 Der Sicherheitsmanager

Der SecurityManager ist eine Klasse innerhalb vom Java-System (als abstract definiert), die als zentrale Entscheidungsstelle der Sicherheitspolitik eines Systems in Bezug auf Applets verstanden werden kann. Sie ist die vierte Ebene in der Sicherheitsphilosophie und die stärkste Stufe. Der SecurityManager überprüft als letzte Instanz der Sicherheitskette alle sicherheitsrelevanten Operationen eines Java-Programms zur Laufzeit. Das bedeutet im Fall von Applets, dass selbst ein Applet, das sogar den Classloader überwunden hat, sich nicht sicher fühlen darf. Der SecurityManager wird immer automatisch beim Start eines Browsers bzw. des Appletviewers gestartet und bleibt so lange im Hintergrund aktiv, bis der Browsers bzw. der Appletviewer wieder beendet wird. Diese Implementierung des SecurityManager lässt sich nicht abstellen. Wird innerhalb eines Applets eine unerlaubte Operation ausgeführt, löst dies eine SecurityException aus.

Sicherheitsrelevante Operationen eines Applets zur Laufzeit sind u.a. das Lesen und Schreiben von Dateien und der Aufbau von Online-Verbindungen. Die Art der Beschränkung durch den SecurityManager hängt jedoch sehr stark von Umgebung der Applets ab. Dies bedeutet, dass der SecurityManager zwischen Applets unterscheidet, die aus dem Netz oder vom lokalen System geladen wurden. Des Weiteren ist es ein massiver Unterschied, ob ein Applet in einem Browser (und welchem) gestartet wird oder im Appletviewer.

Ein Applet gilt übrigens nur dann als lokal, wenn es sich im CLASSPATH (bzw. JDK 1.1) bzw. im bei der Installation festgelegten Suchpfad des SDK 2 befindet. Nur auf dem lokalen System abzulegen genügt nicht. Dies bedeutet, dass Klassen, die sich in einem so spezifizierten Verzeichnis befinden, gegenüber dort nicht abgelegten Klassen erweiterte Rechte haben. Zusammengefasst werden geladene Klassen in Java in größere Gruppen, welchen dann unterschiedliche Rechte zugeordnet werden. Das dahinter liegende Konzept heißt Name Space und bedeutet, dass jede geladene Klasse nach ihrem Namen und dem Herkunftsort identifiziert werden kann.

Die diversen Sicherheitseinstellungen kann man grob in Lese- bzw. Schreibzugriffe auf lokale Ressourcen, Aufbau von Online-Verbindungen über Netzwerke und die Manipulation eines Threads durch einen anderen Thread klassifizieren. In Bezug auf Lese- bzw. Schreibzugriffe auf lokale Ressourcen und Netzzugriffe kann man von der Java-Theorie her Applets in vier Sicherheitsstufen eingliedern:

In Bezug auf Sicherheit sind die Defaulteinstellungen des Appletviewers recht offen. Der Appletviewer überlässt dem Anwender sehr viel Freiheit, welche Sicherheitseinstellungen er vornehmen möchte. Viele Browser sind bzgl. der Sicherheitsvorkehrungen bei Java-Applets sehr viel restriktiver. Bereits für lokale Applets lassen viele Browser keine Festlegung - insbesondere kein Löschen - von Lese- und Schreibverzeichnissen oder -dateien zu. Lediglich das Lesen von einigen Feldern (etwa user.name) oder Bibliotheken, Fensteröffnungen ohne Warnung und die relativ freie Online-Verbindung werden zugestanden. Nicht lokale Applets werden sogar bei einigen Browsern fast vollständig kastriert. Außer einem Hilferuf zum eigenen Host dürfen sie fast nichts (außer bunte Bilder im Browser malen). So etwas ist als Defaulteinstellung sicher gut, aber ob obendrein eine Freigabe durch einen kundigen Anwender zu unterbinden ist, darf diskutiert werden.

Es wird aufgefallen sein, dass bisher im Zusammenhang mit dem SecurityManager fast nur von Applets die Rede ist. Dies ist kein Zufall, denn eigenständige Java-Applikationen sind dessen Restriktionen nicht automatisch unterworfen. Eine eigenständige Java-Applikation darf defaultmäßig innerhalb des Java-Interpreters fast alles tun. Dies ist sinnvoll, wenn man beispielsweise eine Dateiverwaltung oder eine Textverarbeitung in Java erstellen möchte. Um eigenständige Java-Applikationen der Kontrolle des SecurityManagers zu unterwerfen, muss man explizit die Klasse SecurityManager aus dem Paket System im Source implementieren. Installieren des SecurityManagers erfolgt am besten in der ersten Zeile der main()-Methode. Dazu kann die folgende Source-Zeile verwendet werden:

System.setSecurityManager(new MeinSpeziellerSicherheitsChef());

Wenn der SecurityManager eine bestimmte Operation unterbinden soll, muss die dafür relevante Methode entsprechend überschrieben werden. Wenn jedoch der SecurityManager in einer Applikation implementiert wurde, wird jede nicht überschriebene Security-Methode eine SecurityException auslösen, sofern das zugehörige Ereignis ausgelöst wird. Deshalb ist hier viel Sorgfalt vom Programmierer gefordert.

14.1.8 Digitale Unterschriften eines Applets und Verschlüsselung  in Java

Eine wichtige Neuerung im Sicherheitsbereich vollzog Sun mit der Version 1.1 des JDK im ersten Quartal 1997. Seit dieser Version können Applets und Daten (Bilder, Sounds usw.) mit einer digitalen Unterschrift versehen werden. Dadurch kann ein Applet eindeutig seinem Hersteller zugeordnet werden. Umgekehrt kann man bei einer fehlenden digitalen Unterschrift eine Ausführung des Applets unterbinden. Die Sicherheitsschnittstelle von Java bietet seit der Version 1.1 eine Unterstützung für die so genannte Public-Key-Verschlüsselung an, was Java in Bezug auf das Versenden von Daten über das Internet erheblich aufgewertet hat. Die Tools des SDK 2 und das dort außerordentlich erweiterte Sicherheitskonzept hat gerade in diese Richtung noch einmal erhebliche Fortschritte gebracht.

14.1.9 Native Code

Ein erhebliches Sicherheitsproblem bei der Analyse eines Java-Programms ist die Möglichkeit zur Einbindung von nativem Maschinencode in Java. Im Gegensatz zu dem Java-Zwischencode (einem relativ leicht zu analysierenden Bytecode) lässt sich Maschinencode nicht so einfach untersuchen. Java versucht, dieses Problem mit dem SecurityManager in den Griff zu bekommen, der die systemkritischen Ressourcen sichert. Trotzdem bleibt hier sicher ein Restrisiko, und es ist eines der wichtigsten Argumente gegen die Verwendung von nativem Code in Java-Programmen (neben dem Verlust der Plattformunabhänigkeit).

14.1.10 Weitere unerwünschte Aktionen

Es gibt natürlich Sicherheitsfragen, die nicht ohne Weiteres in Java behandelt werden können. Es kann nicht Aufgabe der Entwicklungsumgebung sein, hier einen absoluten Schutz zu garantieren. Dazu zählen etwa die übermäßige Beanspruchung der Rechnerleistung oder des Hauptspeichers des Clients, etwa durch den Start einer beliebigen Menge an Threads, ein Aufrufen von Fenstern über eine Endlosschleife oder auch unerwünschte Inhalte von Applets. Eine andere Art von Sicherheitsverletzungen können aus den immer schon vorhandenen Schwächen der Internet-Protokolle entstehen. Hier hat Java keinerlei Kontrollmöglichkeiten auf technischer Ebene.

Weitere denkbare Aktivitäten von Java-Applets und Programmen sind Aktionen wie Sperren von Ressourcen, unerwünschten Effekte auf Ausgabegeräte oder Diebstahl der Identität eines Benutzers, um mit dieser Aktivitäten auszuführen (etwa Online-Überweisungen). Java unterbindet solche Aktionen wie wir gesehen haben weitgehend. Vollkommen geht so etwas aber technisch nie, sonst kann man keine funktionstüchtigen Programme erstellen. Aber in diesem Bereich sind andere aus dem Internet kommende Programme (vor allem ActiveX-Controls) wahre Meister der potenziellen Schädigung, wie diverse Tests gezeigt haben. Damit diese Behauptung nicht ganz ohne Fundament im Raum steht (und die Qualität des Java-Sicherheitskonzeptes noch deutlicher wird), soll kurz das ActiveX-Sicherheitskonzept (?) angerissen werden.

14.2 ActiveX-Sicherheitskonzept im Vergleich

Um ActiveX-Controls im Vergleich mit Java-Applets zu sehen, wollen wir zuerst kurz klären, was es mit diesen ActiveX-Controls überhaupt auf sich hat.

14.2.1 Was sind ActiveX-Controls?

ActiveX-Controls werden oft als Microsoft-Alternative zu Java-Applets gesehen. Der Begriff ActiveX bezeichnet jedoch nach Aussage von Microsoft keine einzelne Technik oder SDK, sondern ist ein übergeordneter Name für Microsofts Internet und Multimedia-Technologien. Unter ActiveX ist eine Verbindung von vielen verschiedenen Entwicklungstechniken zu verstehen, die alle auf dem Component Object Model (COM) und/oder der Win32 API aufbauen. ActiveX ist ein ganzes Set von offenen Techniken, die die Leistungsfähigkeit von PCs auf das Internet/Intranet und Netzwerk allgemein übertragen soll. Dieses Set wird permanent von Microsoft weiterentwickelt und in Windows integriert. Insbesondere versteht Microsoft die ActiveX-Technologie nicht als direkte Konkurrenz zu Java, sondern als eine Ergänzung. Allerdings sollten sich dann die Entwickler darüber im Klaren sein, dass sie eine Haupteigenschaft von Java aufgeben, wenn sie ActiveX mit Java verbinden - die Plattformunabhängigkeit. ActiveX ist nämlich im Gegensatz zu HTML oder Java explizit nicht plattformunabhängig, sondern läuft (zurzeit) nur auf einer Computerarchitektur und einer Betriebssystemfamilie - INTEL-PCs und WINDOWS (und mit Einschränkungen auf Power Macintosh). Von der Einschränkung des potenziellen ActiveX-"Kundenkreises« auf die WINTEL-Plattform verspricht sich Microsoft ganz massive Vorteile. ActiveX-Controls sind in der Lage, alle Leistungen des Betriebssystems Windows auszuschöpfen. Sie sind eine direkte Nachfolgegeneration der OCX-Controls, die wiederum ja eine speziell für die 32-Bit-Umgebung von Windows 95/NT hergeleitete Weiterentwicklung der VBX-Controls sind.

Ein ActiveX-Control kann also auf alle Möglichkeiten des Win32-API zurückgreifen und wird auch als ein in eine HTML-Seite eingebundenes Element genauso aussehen und zu bedienen sein wie ein »normales« Windows-Steuerelement.

Im Mittelpunkt der Microsoft-Internetphilosophie steht die OLE-Funktionalität (Object Linking and Embedding, Objekte verbinden und einbetten) von Windows. Lange war die OLE-Technik nur als Verbindung von dynamischem Linken (der DD> = Dynamic Data Exchange) und statischem Einbetten (in etwa wie der Datenaustausch über die Zwischenablage), beziehungsweise als eine Erweiterung dieser beiden Techniken um integrierte Hinweise auf ihre Ursprungsanwendungen bekannt. Insbesondere konnten die OLE-Objekte lange nur lokal, das heißt auf einem Rechner eingesetzt werden. Als Beispiel sei die Einbindung einer EXCEL-Tabelle in WINWORD genannt.

Im Rahmen der Netzwerkentwicklung von Windows wird die lokale Einschränkung aufgehoben. Die Weiterentwicklung von OLE (DCOM = Distributed Component Object Model) war schlichtweg die Übertragung der OLE-Technik auf Netzwerke und vor allem das Internet. Mit dieser Technik spielt es keine Rolle mehr, ob ein Objekt auf dem lokalen Rechner oder einem beliebigen Server im Netz beheimatet ist. Auf Grund der integrierten Hinweise auf ihre Ursprünge wird bei einer Aktivierung eines externen Elements der zugehörige Rechner kontaktiert und dort die notwendige Aktion ausgeführt. >

Eine besondere Art von OLE-Objekten sind die Windows-Steuerelemente, die Controls. Auch bei den ActiveX-Controls handelt es sich wie schon erwähnt um eine Weiterentwicklung der herkömmlichen OLE-Controls. Vor allem sind die ActiveX-Controls gegenüber den OCX-Controls auf das Wesentliche reduziert und damit verglichen mit diesen bedeutend kleiner. Die OCX-Controls schleppen eine Unmenge an im Prinzip überflüssigem Ballast aus der MFC (Microsoft-Foundation-Classes) mit, der hier durch ein neues Konzept weggelassen werden kann.

ActiveX-Controls verzichten zudem auf eigene Fenster, sondern delegieren diese Aufgabe an den Container, beispielsweise einen Webbrowser. Neben der Verkleinerung der Controls bringt dieses Verfahren einen weiteren Vorteil - die Controls sind nicht mehr an die Fensterform gebunden. Jede denkbare Form ist im Prinzip realisierbar. Allerdings hat der Container dann eine Menge zu tun, um »Löcher« oder »Flicken« im Bildschirm zu verhindern und Benutzerinteraktionen des Controls zu verarbeiten.

ActiveX-Controls lassen sich wie Java-Applets in jede HTML-Seite einbinden. Die ActiveX-Controls werden wie Java-Applets bei Bedarf automatisch aus dem Internet auf den Client geladen und installiert. Das HTML-<OBJECT>-Tag bindet das ActiveX-Control in die Webseite ein. Diese kann ja seit HTML 4.0 auch zum Einbinden von beliebigen Objekten (insbesondere auch Applets) in eine Webseite genutzt werden. Ursprünglich wurde die Object-Tag-Syntax nur für ActiveX-Controls verwendet:

<OBJECT CLASSID = "[wert]" ID = "Name" WIDTH=[Wert] HEIGHT=[Wert]>
  [ActiveX-Control-Eigenschaften]
</OBJECT>

Die neuere Variante des Tags referenziert ActiveX-Controls etwas anders. Etwa so, als ob man ein Plug-In für die JVM als ActiveX-Control angeben möchte:

<OBJECT classid=
"clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 300 HEIGHT = 200 codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-
win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "SwingApplet1.class" >
<PARAM NAME="type" 
  VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
</OBJECT>

Bei beiden Varianten gilt aber, dass bei der Referenzierung mit CLASSID das Control über einen weltweit eindeutigen 128-Bit-Wert identifiziert und mit WIDTH=[Wert] HEIGHT=[Wert] die Größe des Controls festgelegt wird. Über die CLASSID kann ein Browser entscheiden, ob ein Control bereits geladen wurde und ob es ggf. eine neuere Version eines bereits vorhandenen Controls ist. Auf dieser CLASSID baut jedoch zugleich das Sicherheitskonzept von ActiveX auf.

14.2.2 Sicherheitskonzept von ActiveX

Für ActiveX-Controls gibt es eigentlich gar kein echtes Sicherheitskonzept, denn der Anwender muss im Wesentlichen einer Registrierungsnummer des Controls vertrauen, die als digitale Unterschrift über spezielle Tools der ActiveX-SDK in diese eingebaut wurde. Sofern ein Anwender ein ActiveX-Control auf seinen Rechner lädt, wird diese digitale Unterschrift überprüft und - falls der Browser entsprechend konfiguriert ist - bei fehlender Registrierungsnummer das Laden verweigert. Diese Überprüfung lässt sich zu allem Überfluss auch noch bei manchen Browsern vollständig deaktivieren.

Wer nicht glaubt, dass ActiveX-Controls böse Dinge mit dem lokalen Rechner anstellen können, wenn die Sicherheitsschranke zum Download nicht zertifizierten Codes deaktiviert ist, sollte im Internet einmal gezielt nach Demos suchen. Es gibt zahlreiche Webseiten, die als Demo für die Unsicherheit von ActiveX-Controls dienen. So gab es schon sehr früh das Control Exploder (kein Schreibfehler - http://www.halcyon.com/mclain/ActiveX), das einen PC aus einer Webeite heraus sauber herunterfährt. Wohl bemerkt, es handelt sich nicht um einen Virus, sondern ein ActiveX-Control zu Demonstrationszwecken. Auf der Seite finden Sie zahlreiche interessante Hinweise zu dem Thema.

Abbildung 14.3:  ActiveX oder wie man Nuklearbomben in Webseiten einbindet

Microsoft teilt zwar die Internetwelt in seinem Browser in vier Zonen ein, für die unterschiedliche Sicherheitstufen eingestellt werden (Internetzonen, Lokale Intranetzone, Zone für vertrauenswürdige Seiten und Zone für eingeschränkte Seiten). Je nach eingestellter Stufe (von hoch bis angepasst) werden verschiedene Maßstäbe an das Zertifikat gestellt. Die einzelnen Zonen haben jeweils voreingestellte Sicherheitslevel, sind also eigentlich nur eine andere Ausdrucksweise für die Sicherheitslevel (und bieten zusätzlich etwas Verwaltungskomfort). Nur in der niedrigen Stufe kann die Überprüfung der Zertifizierung vollkommen abgeschaltet werden.

Aber noch einmal zurück zu der digitalen Unterschrift. Was bringt diese an Sicherheit und woher kommt sie überhaupt? Diese digitale Unterschrift bekommt ein ActiveX-Control, sobald es sich (d.h. sein Entwickler) bei einer von Microsoft lizensierten Organisation registrieren lässt, etwa bei der Firma Verisign.

Die Funktion des ActiveX-Control wird allerdings nicht überprüft und es wird damit nicht gesagt, dass das Control harmlos ist. Aber zumindest weiß der Anwender im Schadensfall, wer ihm die Festplatte zerstört hat. Wenn das Control über das Netz geladen wird, erscheint ein Hinweis, dass das Control von der Firma xyz als vertrauenswürdig eingestuft wurde. Das hilft zwar nichts, aber es beruhigt doch ungemein, dass Microsoft zumindest glaubt, niemand bringe ein unregistriertes (d.h. ohne oder mit gefälschter ID) Control in Umlauf. Außerdem hat noch niemand in der EDV-Welt etwas von fehlerhaften Programmen gehört. Sämtliche Naturgesetze stellen doch sicher, dass Programme nie Fehler haben. Oder ist Ihnen jemals ein Fehler in einem Programm untergekommen? Wie kann da ein ActiveX-Control Fehler haben? Eine Überprüfung ist also rein naturwissenschaftlich überflüssig. Sie stimmen sicher zu, dass dies unmöglich ist, oder :-)?! Aber im Ernst, das Registry-and-Trust-Sicherheitskonzept von ActiveX-Controls liegt auf dem Niveau der Aussage »Für was brauche ich einen Sicherheitsgurt, ich habe doch ein vierblättriges Kleeblatt im Handschuhfach« (Bill Gates möge entschuldigen). Nicht umsonst lassen sich mit (zugegeben meist unregistierten) ActiveX-Controls alle möglichen Dinge anstellen, die einem Anwender schaden können. Dagegen kann man glatt sämtliche Schwachstellen im Java-Komzept fast vergessen. Wenn Sie wollen, können Sie die (Missbrauchs-)Möglichkeiten von ActiveX-Controls gerne mit der Datei activeX.html testen. Sie finden sie auf der Buch-CD oder unter http://rjs.de/activeX.html (Groß- und Kleinschreibung beachten)1. Laden Sie die Datei im Internet Explorer mit herunter gelassenen Toren, d.h. mit aktivierten ActiveX-Controls (auch nicht-signierte) und geöffneter Internet-Verbindung. Das in der Webseite integrierte ActiveX-Control zeigt Ihnen im Internet Explorer im Rahmen der Webseite den Inhalt der Festplatte C: an. Sie können beliebig Verzeichnisse öffnen, Ansichten wechseln und auch Kontextmenüs aktivieren und deren Befehle nutzen. Mehr an Schaden verursacht das Control erst einmal nicht, aber dennoch - es ist eine Einladung zum offenen Missbrauch des eigenen Rechners.

Abbildung 14.4:  Der Dieb klopft an (zumindest, wenn nicht alle Sicherheitseinstellungen vollkommen deaktiviert sind).

Abbildung 14.5:  Der Dieb ist drin und wildert auf  der Festplatte.

Es ist bezeichnend, dass die Unsicherheit von ActiveX auf der im August stattgefundenen HIP 97, dem größte Hackertreffen Europas in Almere, Holland, mit 2500 Teilnehmern eines der Hauptthemen war.

Mehr Informationen zum ActiveX-Sicherheitskonzept und ActiveX im Allgemeinen (FAQ) gibt es im Internet unter der bereits genannten Adresse (Contra) http://www.halycon.com/mclain/activeX/2 oder als Pro-Anwalt http://www.microsoft.com/activex/ bzw. http://www.microsoft.com/com/.

Abbildung 14.6:  Pro-ActiveX-Control-Infos von Microsoft

14.3 Bekannte Sicherheitslücken der Java-Vergangenheit

Selbstverständlich gab und gibt es auch in Java diverse Sicherheitslücken. Absolute Sicherheit ist eine Illusion und kann man höchstens von der Religion erwarten. Darüber wird es sicher keine Diskussionen geben.

Einige Bugs in Java wurden in der Vergangenheit ziemlich bekannt. Deshalb sollen sie angesprochen werden. Die Auswahl erhebt aber keinen Anspruch auf Vollständigkeit.

14.3.1 Der Bytecode-Bug

Manche Festplattenzugriffe durch Applets sind nicht destruktiv und es ist sicher nicht jedermanns Sache, vor dem Start eines Applets jedes Mal die Optionen des Browsers umzustellen, wenn man ein Applet verwenden will, das Systemzugriffe benötigt. Aber wer weiß schon genau, was er dann auslöst, wenn er - sogar bewusst - Festplattenzugriffe erlaubt? Zwar lassen sich viele destruktive Verhaltensweisen eines Applets abfangen, jedoch in älteren Java-Versionen konnten die Sicherheitseinstellungen von Containern von Java-Applets bzgl. Festplattenzugriffen durch Simulation eines Laufzeitfehlers ausgehebelt werden. Genauer handelte es sich dabei um einen Bug im Bytecode-Verifizierer, der eine Sicherheitslücke im Java-System bedeutete. Laut Aussagen der Entdecker des Fehlers (Drew Dean, Ed Felten und Dan Wallach) konnte ein Applet fähig sein, Maschinencode zu erzeugen, der in der Lage war, ein Applet mit gleichen Rechten auszustatten, wie sie der Anwender auf dem Rechner besitzt. Anschließend durfte ein Applet alle Befehle aufrufen, die dem Anwender erlaubt waren. Der Fehler lag in dem Teil des Interpreters, der über das Netz geladene Applets auf ungültige oder verbotene Befehle hin überprüft. Ein Applet konnte bei genauer Kenntnis dieses Fehlers den Restriktionsmechanismus außer Kraft setzen. Dieser Fehler ist seit Jahren beseitigt.

14.3.2 Schwarze Witwen und der DNS-Bug

Neben der Gefahr eines destruktiven Verhaltens auf Datenträgern lauert hinter Java-Applets immer ein weiteres Schweinchen. Spionage! Wenn Sie Online arbeiten, können Sie selbstverständlich nicht nur Daten empfangen. Bewusst versenden Sie E-Mails, Dateien oder permanent Anforderungen für Webseiten oder FTP-Pakete. Applets können im Prinzip Mechanismen integriert haben, die ebenfalls - allerdings heimlich - Daten versenden, wenn eine Online-Verbindung besteht, z.B. den Inhalt Ihrer Datenträger oder die Adressen von mitprotokollierten Internetseiten. Keine sonderlich beruhigende Vorstellung. Von der Java-Theorie her darf es das zwar nicht geben, aber die ersten Spionage-Applets wurden Mitte 1996 unter dem Namen »Schwarze Witwen« bekannt. Zwar lassen sich im Prinzip von vielen Browsern bzw. dem Appletviewer sowohl Lesezugriffe auf die Festplatte als auch die Kommunikation mit Hosts unterbinden, aber Java war in der Vergangenheit in der Lage, auf einigen Plattformen über den Umweg eines DLL-Funktionsaufrufs diese Hürde zu umgehen. Die ungewollten Verbindungsaufnahmen gingen in der Vergangenheit sogar so weit, dass prinzipiell beliebige Server von Java-Applets kontaktiert werden konnten. Dabei sollte von der Java-Theorie her ein Applet bei entsprechender Einstellung des Containers (Appletviewer bzw. Browser) nur maximal Kontakt zu dem Server aufnehmen können, von dem es stammt (wer unbeschränkte Kontaktaufnahme im Appletviewer oder in einen justierbaren Browser eingestellt hat, der verdient es einfach nicht besser).

Ein Fehler, der sowohl Netscape 2.0 als auch den Appletviewer JDK 1.0 betroffen hat, ist der so genannte DNS-Bug. Der Fehler basierte darauf, dass ein Applet-Programmierer einem beliebigen Host im Internet eine zusätzliche IP-Adresse und einen dementsprechenden Namen zuweist. Diese Adresse muss dann aus der Domain stammen, aus der die Applets angefordert werden. Weiterhin muss sie an erster Stelle innerhalb der Liste der IP-Adresse stehen. Java führt eine Kontrolle durch, ob eine Verbindung zu dem Server erlaubt ist und stellt dann direkten Kontakt zum ersten Eintrag in der Liste her, sogar wenn dies nicht die Ursprungsadresse war. Es gab also somit keine Überprüfung der IP-Adressen, sondern nur der Namen. Durch diese Lücke war es ebenso möglich, jede Firewall auszutricksen. Dieser Fehler ist jedoch offiziell seit der Netscape-Version 2.01 und der JDK-Version 1.01 behoben. Für neuere Varianten ist das Problem irrelevant.

14.3.3 Der CLASSPATH-Bug

Auch der so genannte CLASSPATH-Bug in Verbindung mit dem Navigator 2.01 machte deutlich, dass das Sicherheitskonzept von Java in der Vergangenheit Lücken hatte. Laut der Spezifikation kann ein Applet nur lokale Java-Klassen nachladen. Das waren im damaligen Konzept also Klassen, die sich innerhalb der mit CLASSPATH gesetzten Pfade befinden. Die dort befindlichen Klassen besitzen erweiterte Zugriffsrechte. Deshalb wurde schon von Anfang an empfohlen, dort nur die Originalklassen von Sun und eigene, getestete Klassen zu platzieren. David Hopwood von der Oxford University hat aber nun entdeckt, dass es mit dem Interpreter von älteren Netscape-Versionen trotzdem möglich ist, Klassen aus beliebigen lokalen Verzeichnissen nachzuladen. Diese haben dann ebenfalls erweiterte Rechte. Dieser Bug ist in allen Nachfolgeversionen des Navigators 2.01 behoben und hat im Prinzip nichts mit dem eigentlichen Java-Sicherheitskonzept zu tun. Zusätzlich wird ja auch im SDK 2 der CLASSPATH nicht mehr verwendet, sondern ein neues Konzept zur Freigabe von Rechten verfolgt.

14.3.4 Weitere Bugs

Den gerade explizit genannten bekannteren, frühen Bugs folgten diverse weitere. In der Hochphase der Java-Euphorie schien es zu einer Art Sport geworden zu sein, Bugs im Java-Sicherheitskonzept zu finden, so konstruiert und unwahrscheinlich die Ausgangssituationen auch waren. Hauptsache, das Konzept hatte irgendeine Lücke. Im Frühsommer 1997 gingen beispielsweise Horrormeldungen durch die Medien, dass Forscher der University of Washington im Rahmen des Kimera Project 24 neue Sicherheitsrisiken in der damals aktuellen Version des JDK 1.1 entdeckt hätten. Bestätigt wurde davon nur ein echter Fehler. Dennoch entstand der Eindruck, dass, wo Rauch ist, meistens auch Feuer ist. Warum jedoch diese Diskrepanz? Es liegt wohl im Wesentlichen an zwei Dingen. Ein Aspekt ist die Bewertung der gefundenen Bugs. Was ist ein Sicherheitsrisiko und was ein Fehler, der nur in extremen Ausnahmesituationen auftritt? Ein »Fehler« wurde beispielsweise in dem Teil der virtuellen Java Maschine entdeckt, der den Bytecode überprüft. Beim Füttern des »Bytecode Verifiers« mit zufällig gewählten Bytefolgen konnte es zu einem Stack-Überlauf kommen und damit zum Absturz der JVM (auch nach allgemeiner Einschätzung kein Sicherheitsrisiko, nichtsdestotrotz hatte SUN natürlich ein Bug-Fix entwickelt). Wer mit Windows-Software arbeitet, wird garantiert zustimmen, dass dort Abstürze und Fehlleistungen der Windowsprogramme oder des Betriebssystems unter weniger konstruierten Bedingungen zur Tagesordnung gehören. Dennoch hisst niemand gleich die Panikflagge. Ein weiterer Grund für die Diskrepanz der Fehlerzahlen lag in den unterschiedlichen Testmethoden.

Grundsätzlich wurde um Java-Bugs viel Sturm in einem Wasserglas veranstaltet. Man unterscheidet bei den Bugs zwischen Security Bugs, System Bugs und Language Bugs. Echte Sicherheitsbugs sind über die Java-Zeit nur äußerst selten entdeckt worden. Und in der letzten Zeit nehmen die Meldungen rund um Sicherheitsprobleme von Java immer mehr ab. Dies darf als gutes Zeichen gewertet werden, denn das Interesse bestimmter Kreise, Sun und Java zu schaden, ist nicht geringer geworden. Wenn diese Kreise keinen Wind mehr machen, haben sie auch nichts Erwähnenswertes mehr gefunden.

14.3.5 Informationen zur Sicherheit

Mehr Informationen zu bisher bekannt gewordenen Java-Bugs und allgemeinen Sicherheitsfragen rund um Java gibt es unter http://java.sun.com/security/. Dies betrifft sowohl allgemeine FAQs, aber auch eine Bug-Chronologie.

Abbildung 14.7:  Sicherheitsinformationen zu Java

14.4 Zusammenfassung

Es gibt keine absolute Sicherheit. Auch nicht in Java. Zwar sind mittlerweile diverse Bugs erkannt und beseitigt, aber wo eine Sicherheitslücke erkannt wird, können sich durchaus noch weitere verbergen. Darüber muss man sich im Klaren sein.

Aber man sollte beachten, dass die Sicherheitslücken in Java sehr spezielle Situationen voraussetzen und von subversiven Elementen nur sehr schwierig zu nutzen sind. Auch das sicherste Verkehrsmittel der Welt, das Linienflugzeug, stürzt gelegentlich ab. Dennoch fliegen viele Leute, weil es im Verhältnis zum Risiko einfach die beste - und teilweise einzig sinnvolle - Lösung ist. So sollte man auch das Java-Sicherheitskonzept sehen. Und wem es zu ungenügend erscheint, der sollte nur noch einmal einen kurzen Blick auf das ActiveX-Control-Konzept werfen. Obwohl es noch den letzten Beweis schuldig ist, scheint das Java-Sicherheitskonzept zu den derzeit besten Systemen auf dem EDV-Markt zu zählen.

1

Die Webseite http://www.astalavista.de, wo diverse Hacker- und Auswertungsmöglichkeiten im Rahmen einer HTML-Seite (meist recht harmlose Techniken wie Cookies oder Scripte) gezeigt werden, verwendet das ActiveX-Control als Highlight auch.

2

oder - falls die Seite verlagert wurde - in einem anderen Verzeichnis unter diesem DNS-Namen


© Copyright Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH
Elektronische Fassung des Titels: Java 2 Kompendium, ISBN: 3-8272-6039-6 Kapitel: 14 Java-Sicherheit