Verletzungsgefahr

Schon mit der ersten Welle der Begeisterung kamen Befürchtungen auf, Java werde eine Flut von Sicherheitsproblemen mit sich bringen. Die Angst war nicht ganz unbegründet.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 5 Min.
Von
  • Ingo T. Storm

In den letzten Wochen machte so manche Meldung die Runde, daß Suns und Netscapes Programmiersprachen Java und JavaScript riesige Sicherheitslöcher in ansonsten gut abgeschottete Netzwerke reißen könnten. Die Dinge liegen ähnlich wie bei der zunächst größtenteils unreflektierten Begeisterung: in viel Lärm geht der Kern der Nachricht unter.

Zunächst einmal ist es wichtig, zwischen Java und JavaScript sowie zwischen Sun und Netscape zu unterscheiden. Java ist eine von Sun entworfene portable Programmiersprache, für die diverse Interpreter existieren; unter anderem der Netscape Navigator. JavaScript ist dagegen die `gehobene Makrosprache' des Netscape Navigators. Java-Programme, auch Applets genannt, werden als separate, vorkompilierte Dateien aus dem Netz geladen und anschließend von einem Java-Interpreter ausgeführt. JavaScripts sind dagegen als Klartext in die WWW-Seite eingebettet.

Die Java-Spezifikation zählt eine Menge interner Mechanismen auf, die Sicherheitsrisiken minimieren sollen. Theoretisch unterliegen Java-Programme je nach Herkunft verschiedenen Einschränkungen, was den Zugriff auf den Rechner angeht, auf dem sie laufen: ein vom Server www.ix.de geladenes Applet darf nur zu genau diesem Host Kontakt aufnehmen. Es darf weiterhin nur auf lokale Verzeichnisse zugreifen, die der Benutzer explizit freigegeben hat. (Der Java-Interpreter des Netscape Navigator unterbindet jeden Zugriff auf lokale Dateien). Nach ausgiebigem Studium haben nun zunächst Steve Gibbons und dann drei Forscher der Universität Princeton einen Bug in den Java-Quelltexten von Sun entdeckt. Die Routine, die eine Netzwerkadresse daraufhin überprüft, ob ein Applet tatsächlich nur den Server kontaktieren will, von dem es stammt, berücksichtigt nur den Rechnernamen anstelle seiner Netzwerkadresse (IP-Nummer). Das Applet kann nun den `Domain Name Server' (DNS) genannten Rechner `überlisten', der Netzwerknamen und - nummern einander zuordnet und anschließend Verbindung zu jedem beliebigen Rechner aufnehmen - auch zu solchen, die eigentlich durch eine sogenannte `Firewall' vor Zugriffen von außen geschützt sein sollten. Sun hat dieses Problem inzwischen behoben und ein Update des Java Development Kits bereitgestellt. Auch im Netscape Navigator 2.01 soll der Fehler behoben sein. Dagegen spricht allerdings der Bericht von Eric Williams, laut dem das Problem auch mit dieser Version zu reproduzieren ist. Das Princeton-Trio stieß nur wenig später auf ein weiteres und weit ernsteres Problem. Auch der Teil des Java-Interpreters, der über das Netz geladene Applets auf ungültige oder `verbotene' Befehle durchsucht, hat einen Fehler. Applets können bei genauer Kenntnis des Fehlers die normalerweise gültigen Restriktionen außer Kraft setzen und alle Befehle ausführen, zu denen der Benutzer des Browsers berechtigt ist - und dazu gehört das Löschen von Dateien. Auch hierfür will Sun noch vor Erscheinen dieser Ausgabe einen Patch ausliefern, der auch den Java-Lizenznehmern zur Verfügung gestellt wird.

Die dritte ernsthafte Attacke ritt David Hopwood (Oxford University). Laut Spezifiktion kann ein Applet Java-Klassen nachladen, die im `CLASSPATH' stehen. Da dort befindliche Klassen erweiterte Zugriffsrechte besitzen, sollte dieser Pfad nur die `Originalklassen' des Java-Systems und getestete, selbstgeschriebene Klassen enthalten. David Hopwood hat nun entdeckt, daß es dennoch möglich ist, Klassen aus beliebigen lokalen Verzeichnissen nachzuladen, die dann ebenfalls in den Genuß erweiterter Zugriffsrechte kommen. Auch hier hilft das Navigator-Update.

Alle drei Probleme beziehen sich also auf Fehler in der Implementierung und sind keinesfalls systemimmanent. Bei JavaScript dagegen hat Netscape von Anfang an so viele Türen offen gelassen, daß grundsätzliche Zweifel am Konzept angebracht sind. JavaScripts können auf sehr viel mehr Daten auf dem lokalen Rechner zugreifen, als dem Benutzer lieb sein kann. JavaScripts können zum Beispiel unbemerkt im Namen des Besuchers einer Web-Seite Mails verschicken, Verzeichnisse und Dateien des Benutzers lesen und diese Daten über das Netz verschicken und nicht zuletzt die Bewegungen des Benutzers im Netz verfolgen.

Die meisten dieser Probleme sind mit der Navigator-Version 2.01 behoben - mit dem kleinen Schönheitsfehler, daß die Entdecker schon eine Woche später neue Skripte auf Lager hatten, die fast die gleichen unerwünschten Effekte produzierten. Hier scheint Netscape noch einige Arbeit vor sich zu haben.

Es spricht im Moment nicht viel dafür, den Java-Support im Netscape Navigator abzuschalten. Die Java-Bugs auszunutzen ist relativ schwierig - immerhin mußten die Entdecker die Java-Quelltexte gründlich studieren, um sie zu finden. Mit JavaScript Schindluder zu treiben ist weitaus einfacher (siehe http://cip.physik.uni-wuerzburg.de/javascript.html), weswegen ich zur Zeit raten würde, die erst im Navigator 2.01 aufgetauchte Checkbox `Disable JavaScript' in jedem Falle mit einem Häkchen zu versehen. Dummerweise macht die Netscape-Homepage reichlich Gebrauch von JavaScript ... (it) (rm)