Kurz notiert

vorlesen Druckansicht
Lesezeit: 5 Min.
Von
  • Christian Segor

Mit Frontpage Server Extensions (FPSE) ist es so eine Sache. Wer sich für einen Webentwickler hält, rümpft etwas abfällig die Nase - und benutzt sie trotzdem. Vermutlich sind die Erweiterungen, die eine direkte Kommunikation zwischen Frontpage-Editor und Webserver erlauben, auf der Mehrheit aller IIS-Installationen und vielleicht auch auf anderen Webserver anzutreffen.

Praktisch sind sie ja. Formulare und Ähnliches lassen sich mit FPSE einfach schneller und leichter erstellen als ohne; vor allem, wenn man es als HTML-Programmierer nicht für nötig hält, sich mit den zugrunde liegenden Funktionen vertraut zu machen. In diesem Fall übernimmt der so genannte SmartHTML-Interpreter die Arbeit, und zum Erstellen eines Web-Formulars sind nicht mehr als ein paar Mausklicks vonnöten. Leider ist diese Komponente nicht ganz so smart, wie der Name es vermuten ließe: Die in FPSE 2000 enthaltene Version ermöglicht einem Angreifer eine DoS-Attacke; die Nachfolgeversion (in FPSE 2002) enthält einen Puffer, der in bestimmten Situationen zum Überlaufen neigt. Letzteres kann dazu führen, dass der betroffene Webserver beliebigen Code im eigenen (privilegiertem) Sicherheitskontext ausführt. Betroffen sind neben den FPSE auch die SharePoint Team Services (Q324096).

In diesem Zusammenhang sei hier wieder auf das IIS Lockdown Tool hingewiesen, das in der Lage ist, IIS-Installationen abhängig von ihrem geplanten Einsatzgebiet so weit wie möglich abzusichern. Das Tool ist in der Version 2.1 kostenlos unter www.microsoft.com/technet/security/tools/tools/locktool.asp erhältlich. Und wer seinen IIS aktualisieren möchte, installiert gleich noch den neuen Cumulative Patch vom 30. Oktober, der neben fünf neu entdeckten Schwachstellen gleich noch alle vorherigen Sicherheitslöcher stopft (Q327696).

Windows XP bietet es von vorneherein, unter Windows ME und Windows 98 kann man es zusätzlich installieren: Ein eher zweifelhaftes Feature, das es erlaubt, ZIP-Dateien im Windows-Explorer wie Unterverzeichnisse zu verwenden. Die Funktion, die zum Dekomprimieren der Archive dient, enthält einen Speicherbereich, der nicht hinreichend überprüft wird, sodass hier Code in angrenzendes Memory schwappen kann. Der Angreifer muss lediglich dafür sorgen, dass ein Benutzer ein ZIP-Archiv öffnet, in dem sich eine Datei mit einem bestimmten Dateinamen befindet, um bösartigen Code auf der betroffenen Maschine auszuführen. Damit nicht genug: Unter Umständen verschiebt die Funktion Dateien in beliebige Ordner im Dateisystem (also nicht nur innerhalb des ZIP-Archivs), zum Beispiel in den Autostart-Folder (Q329048).

Wer SP1 für Windows XP oder für den IE 6.0 installiert hat, kann den folgenden Absatz überspringen: es geht um eine recht unangenehme Sicherheitslücke in Outlook Express (OE) 5.5 und 6.0. Manchmal möchte man ja sicherstellen, dass der Absender einer E-Mail wirklich der ist, der er zu sein vorgibt. Dann ist es nützlich, wenn der Absender die Nachricht elektronisch unterschrieben hat; zum Beispiel mittels einer S/MIME-Signatur. Leider enthält die entsprechende Unterfunktion in OE einen Fehler, der es einem Angreifer wieder einmal erlaubt, beliebigen Code in den Arbeitsspeicher der betroffenen Maschine zu platzieren und dort auszuführen - und zwar nicht nur, wenn der Benutzer eine derartig präparierte E-Mail öffnet, sondern bereits wenn die Nachricht im Vorschaumodus angezeigt wird. Benutzer von OE sollten den von Microsoft bereitgestellten Patch dringend installieren, oder eines der beiden oben erwähnten Servicepacks, die den Flicken enthalten. Outlook (sozusagen ohne Express) ist übrigens nicht betroffen (Q328676).

Eine frische Windows 2000-Installation zeichnet sich unter anderem dadurch aus, dass die Rechte im Root-Verzeichnis der Systemplatte (in den meisten Fällen ist das die Partition c:) recht großzügig gesetzt sind: Die Everyone-Gruppe hat vollen Zugriff. Das ist normalerweise nicht schlimm, da sich c: nicht im Suchpfad befindet, und ein dort befindliches Programm nur dann läuft, wenn es explizit und mit voller Pfadangabe gestartet wird. Unter bestimmten Umständen allerdings ändert sich der Suchpfad, und c: gehört dann dazu. Dies ist beispielsweise während des Logons der Fall.

Stellt nun ein bösartiger Zeitgenosse eine Datei in das Root-Verzeichnis, die denselben Namen trägt wie ein im Logon-Skript aufgerufenes Programm (was ihm ja aufgrund der Rechte ohne weiteres möglich ist, sofern er Zugriff auf die Maschine hat), kann er beliebige Kommandos im Sicherheitskontext des Benutzers ausführen, der sich gerade anmeldet. Einen Patch gibt es hierfür nicht, aber die Empfehlung seitens Microsofts, die NTFS-Berechtigungen auf c: entsprechend zu ändern (Q327522).

Näheres zu den einzelnen Sicherheitsproblemen sowie die angegebenen KnowledgeBase-Artikel gibt es online. (wm)