Channel Datenbanken

Ist ein möglicher Absturz eine gefährliche Schwachstelle oder einfach nur ein ärgerlicher Bug? Dieser Standpunkt Sicherheit liefert die Antwort.

Ist ein Absturz eine Schwachstelle?

Oder ist es einfach nur ein Programmierfehler? Diese Fragen haben auf der Mailingliste Full-Disclosure zu einigen Diskussionen geführt, nachdem eine DoS-Schwachstelle in Safari 4 Beta gemeldet worden war (verlinkt zu Neohapsis, da die Links im Archiv von Full-Disclosure bei jedem Löschen einer Mail durcheinander gewürfelt werden): Beim Klick auf einen präparierten Link stürzt Safari ab.

Ich habe mir diese Fragen so ähnlich schon öfter gestellt, wenn ich entscheiden musste, ob ich eine Schwachstelle in meine Schwachstellensammlung aufnehme oder nicht. Bei Schwachstellen, die das Einschleusen und Ausführen von Code erlauben, ist die Antwort eindeutig: Das sind Schwachstellen, die ja im englischen Vulnerabilities, also eigentlich Verwundbarkeit, heißen. Problematisch wird es bei DoS-Schwachstellen. Ich persönlich habe mich für folgende Lösung entschieden: Ein Denial of Service liegt immer dann vor, wenn ein Rechner nicht das macht, was er nach dem Willen des Benutzers machen soll UND wenn ein Dritter dafür verantwortlich ist UND der diesen Zustand mit Absicht verursacht. Und so etwas ist eine Schwachstelle.

Viel wichtiger: Die Gefährdung

Damit ist die auf Full-Disclosure veröffentlichte Schwachstelle für mich eindeutig eine DoS-Schwachstelle: Ein Dritter kann dafür sorgen, das der Webbrowser eines Benutzers abstürzt, also nicht das tut, was der Benutzer will. Eine ganz andere Frage ist die nach der Gefährdung durch so eine Schwachstelle. Die ist in diesem Fall minimal: Ein Benutzer klickt einen entsprechenden Link an, Safari stürzt ab, mehr passiert nicht. Safari stürzt bei mir sowieso ab und zu mal ab, genau wie andere Browser auch. Und ob sich der Browser nun an einer ungeschickt aufgebauten Website verschluckt oder über eine absichtlich entsprechend präparierte Seite stolpert, ist dann ziemlich egal. Also: Was solls?

Das gleiche gilt für DoS-Schwachstellen in anderen Anwendungsprogrammen, die z.B. beim Öffnen einer Datei oder der Verbindung mit einem Server zu einem Absturz führen. Vielleicht versucht man es noch ein zweites Mal, danach wird die Datei, der Server oder wie in diesem Fall der Link als "kaputt" eingestuft und das Leben geht weiter.

Ähnlich sieht es bei Schwachstellen im Betriebssystem selbst aus: Eine nur von lokalen Benutzern ausnutzbare DoS-Schwachstelle stellt im Prinzip keine Gefahr da: Der Benutzer hat i.A. kein Interesse daran, den eigenen Rechner aus dem Verkehr zu ziehen, und wenn, dann hätte er auch ohne Schwachstelle genug Möglichkeiten dazu. Minimal bedrohlicher sieht es in Mehrbenutzersystemen aus: Ein Benutzer könnte für alle anderen einen DoS auslösen, aber was hätte er davon, da er selbst ja auch betroffen wäre? Zumal man in den meisten Fällen davon ausgehen kann, das man den eigenen Benutzern ein gewisses Maß an Vertrauen entgegen bringen kann.

Gefährlicher: DoS im Server-Programmen

Ganz anders sieht es aus, wenn die Schwachstelle sich in einem Server-Programm befindet, aus der Ferne ausnutzbar ist und ohne Interaktion eines Benutzers zu einem DoS führt. So stellt z.B. eine Schwachstelle in einem Webserver, die sich durch das simple Senden eines bestimmten TCP-Pakets ausnutzen lässt, um einem Neustart auszulösen, eine hohe Gefährdung dar: Ein Angreifer kann durch fortlaufenden Senden des entsprechenden TCP-Pakets alle anderen Benutzer an der Nutzung des Webservers hindern.

Erst DoS, dann 0-Day-Exploit

Ein weiterer Punkt, der für die Einstufung von Problemen wie dem in Safari als Schwachstelle spricht: Schon manches als DoS-Schwachstelle gemeldete Problem erlaubte am Ende die Ausführung eingeschleusten Codes. "Stürzt ab" kann viele Ursachen haben. Manche lassen sich zu mehr ausnutzen, manche nicht. Manche gemeldeten Schwachstellen befinden sich nach genauerer Untersuchung in ganz anderen Programmen oder Systemkomponenten und haben weitere, anfangs nicht erkannte Auswirkungen. Würden die DoS-Schwachstelle als einfacher Programmfehler abgetan, würde ihre wirkliche Bedeutung vielleicht zu spät erkannt. Die Websense Security Labs haben berichtet, das Cyberkriminelle gezielt nach entsprechenden Meldungen suchen und prüfen, ob die Schwachstellen vielleicht das Einschleusen von Code erlauben.

Auch die andere Richtung ist durchaus möglich, d.h. eine möglicherweise zum Einschleusen von Code ausnutzbare Schwachstelle erweist sich nach näherer Untersuchung als harmlose DoS-Schwachstelle. Ende Januar wurde so eine Schwachstelle im Internet Explorer gefunden: Ein gemeldeter Stacküberlauf war genau das und kein das Einschleusen von Code erlaubender Pufferüberlauf. Es erschien extra ein Eintrag in Microsofts Security Research & Defense Blog dazu: "Stack overflow (stack exhaustion) not the same as stack buffer overflow".

Safari ist raus

Das die Safari-Schwachstelle trotzdem nicht in meiner Datenbank und damit im Bereich "Security aktuell" gelandet ist, hat einen anderen Grund: Safari 4 ist eine Beta-Version, an der noch aktiv gearbeitet wird. Die Schwachstelle wird also sehr wahrscheinlich behoben sein, wenn die Entwicklung abgeschlossen ist, und im Gegensatz zu z.B. Googles Chrome wird wohl kaum jemand Safari 4 Beta ernsthaft einsetzen.

CeBIT - diesmal eine der kurzen Wege

Am Dienstag beginnt wieder die CeBIT. War die im letzten Jahr für mich noch eine der langen Wege, sieht es dieses Jahr sehr viel besser aus: Der Themenbereich Sicherheit konzentriert sich auf Halle 11, einige andere relevante Aussteller sind in Halle 12 und 13 untergekommen. Zwar sind auch in den anderen Hallen Aussteller, die ich besuchen werde, aber zumindest muss man diesmal nicht wie im letzten Jahr um die leerstehende Halle 11 herumlaufen. Das wäre beim sich abzeichnenden typischen CeBIT-Wetter auch nicht gerade Gesundheitsfördernd. Hatschi! Ich bin schon gespannt, was es dieses Jahr neues zu entdecken gibt. Sehr interessant sieht z.B. die GeNUCard von GeNUA aus, ein Hochsicherheits-Paket für Laptops.

Carsten Eilers