Schwachstelle oder nicht - frei nach Hamlet geht es in diesem Standpunkt Sicherheit um die Frage "To be vulnerable or not to be vulnerable, that is the question".

Manchmal kann man darüber streiten, ob ein Fehler eine Schwachstelle ist oder nicht, und manchmal fehlen die nötigen Informationen, um eine behauptete Schwachstelle identifizieren oder prüfen zu können. In den vergangenen Wochen gab es mehrere solcher Fälle.

(K)eine Schachstelle im IIS?

Eine Schwachstelle beim Verarbeiten von Dateien mit mehreren durch ; getrennten Extensions durch Microsofts IIS erlaubt das Einschleusen von ASP-Skripten. Das setzt voraus, dass die Benutzer Dateien heraufladen können und die Dateien in einem Verzeichnis gespeichert werden, in dem sie auch ausgeführt werden können. Das ist eindeutig eine Schwachstelle, oder?

Microsoft stuft die Schwachstelle nicht als solche ein, sondern spricht von einer 'inconsistency', die nur ausgenutzt werden kann, wenn der Server nicht wie von Microsoft empfohlen konfiguriert wurde. OK, es ist also keine Schwachstelle. Oder?

Für das Exploit-Framework Metasploit gibt es ein Modul zur Ausnutzung dieser 'inconsistency'. Die Ausrede "It's not a bug, it's a feature" war schon zu Atari-Zeiten ebenso faul wie unbeliebt. Zumal in diesem Fall nur der IIS 6 unter Windows 2003 dieses Feature aufweist, nicht aber die anderen Versionen. Schwachstelle, keine Schwachstelle, jetzt wieder Schwachstelle. Dabei bleibt es. Oder?

Nun, ich habe noch ein Blütenblättchen zum abrupfen: Der IIS (nur Version 6 unter Windows 2003) übergibt die heraufgeladene Datei mit dem Namen boesesSkript.asp;.jpg beim Aufruf an das ASP-Modul, statt sie als Bild an den Webbrowser zu schicken. Der Apache macht etwas ähnliches: Der übergibt eine heraufgeladene Datei mit dem Namen boesesSkript.php.jpg beim Aufruf an PHP, statt sie als Bild an den Webbrowser zu schicken. Und das ist z.B. nach Einschätzung von Johannes Ullrich, der dieses Verhalten im April 2009 im Handler's Diary des ISC angesprochen hat "not an Apache bug, or a misconfiguration per se. It is more an error of the operator not to read the manual." Gleich und gleich gesellt sich gern: IIS und Apache sind beides Webserver, boesesSkript.asp;.jpg und boesesSkript.php.jpg werden beide an die für die jeweilige Sprache zuständigen Komponenten übergeben, beides sind also auch keine Schwachstellen. Oder?

Wie Johannes Ullrich im Fall des Apache sehr richtig bemerkt hat: "It is more an error of the operator not to read the manual." Beim Apache ist es ein gewolltes, dokumentiertes Verhalten, also ein Feature und weder Bug noch Schwachstelle. Beim IIS dagegen handelt es sich um kein gewolltes und dokumentiertes Verhalten, sondern um eine inzwischen dokumentierte 'inconsistency' - also kein Feature, sondern zumindest ein Bug. Und Fehler, die sich für Angriffe ausnutzen lassen, nennt man normalerweise Schwachstelle. Oder, noch einfacher: Die Anwendung ist durch diese Inkonsistenz angreifbar, also verwundbar - vulnerable. Diesmal ohne 'oder?' - Schuldig im Sinne der Anklage.

(K)eine 0-Day-Schwachstellen in MySQL 5 und Sun Web Server 7?

Toby Kohlenberg hat im Handler's Diary des ISC berichtet , dass Intevydis ein Demo-Video veröffentlicht hat, in dem eine evtl. bisher unveröffentlichte Schwachstelle in MySQL 5 vorgeführt wird. Der Exploit ist laut Intevydis seit August 2009 Bestandteil des Exploit-Packs VulnDisco. Intevydis weist auf ein weiteres Demo-Video hin, dass eine 0-Day-Schwachstelle im Sun Web Server 7 zeigen soll. Auch in diesem Fall ist nicht bekannt, ob es sich wirklich um eine neue Schwachstelle handelt. Schöne Videos - nur: Sie verraten leider fast gar nichts über die Schwachstellen, außer dass sie existieren. Ich habe aber auch schon von Leuten gehört, die noch gar nicht geschriebene Programme als PowerPoint-Präsentationen vorführen.

Im Fall der Schwachstellen wäre natürlich besonders interessant, ob die bereits bekannt sind. Um Schwachstellen eindeutig unterscheiden zu können, gibt es die CVE Identifier, die für jede bekannt gewordene Schwachstelle vergeben werden. Sucht man in der CVE-Datenbank nach MySQL, findet man die ID CVE-2009-4484 mit der Beschreibung

"Buffer overflow in the server in MySQL 5.0.51a on Linux allows remote attackers to execute arbitrary code via unspecified vectors, as demonstrated by the vd_mysql5 module in VulnDisco Pack Professional 8.11. NOTE: as of 20091229, this disclosure has no actionable information. However, because the VulnDisco Pack author is a reliable researcher, the issue is being assigned a CVE identifier for tracking purposes."

Man vertraut dem Finder der Schwachstelle, dass er wirklich eine Schwachstelle gefunden hat, und hat ihr deshalb erst mal eine ID verpasst. Aber mangels weiterer Informationen kann man nicht sicher sein, dass die Schwachstelle nicht bereits bekannt ist und bereits eine andere ID hat. In diesem Fall wäre es hilfreich, wenn die Entdecker ein paar weitere Informationen veröffentlicht hätten. Da sie aber gerne für ihre Arbeit bezahlt werden möchten (was ich sehr gut verstehen kann), sind sie mit der Preisgabe von Informationen zurückhaltend. Die Veröffentlichung der Videos könnte durchaus auch "Marketinggründe" haben. Eine öffentlich bekannte Schwachstelle könnte die Programmentwickler gegenüber einer angemessenen Entschädigung aufgeschlossener machen, aber wenn darüber zu viel bekannt ist, könnte das genau den entgegengesetzten Effekt haben und die Entwickler finden die Schwachstelle anhand der Hinweise selbst. In diesem Fall haben wir also eine Schwachstelle, wissen aber nicht, ob sie wirklich neu ist. Die Frage, ob sie bereits behoben wurde oder nicht, ist dabei zweitrangig: Da alle Programme sowieso immer auf dem aktuellen Stand sein müssen, wurde ein evtl. veröffentlichter Patch sowieso schon installiert. Interessanter wäre die Frage nach möglichen Workarounds für eine nicht behobene Schwachstelle - aber für die Antwort darauf fehlen verwertbare Informationen.

Eine Schwachstelle, die keine Schwachstelle sein soll und trotzdem zu einer Verwundbarkeit führt,
eine Schwachstelle, die vielleicht neu ist oder auch nicht,
wie wäre es jetzt mit einer Schwachstelle, die nur behauptet wird?
Eine? Ach was, gleich drei:

(K)eine Schwachstellen in Media-Playern?

Vorige Woche wurden von 'Rewterz' mehrere Schwachstellen in verschiedenen Media-Playern gemeldet:
'REWTERZ-20100101 - n.player Local Heap Overflow Vulnerability',
'REWTERZ-20100102 - Nemesis Player (NSP) Local Denial of Service (DoS) Vulnerability' und
'REWTERZ-20100103 - Ofilter Player Local Denial of Service (DoS) Vulnerability'.

Als Beispiel hier die Beschreibung aus dem Advisory zum n.player:

 
4) Description of Vulnerability
 
Rewterz has discovered vulnerability in n.player. This vulnerability
could lead to execution of code with the privileges of the current
process or user.
 
This vulnerability exists in the handling of application skin selection
by the user. We chose not to provide detailed information about
the location of the vulnerability and how to reproduce it because the
author hasn't confirmed this vulnerability. We can pass a long argument
with some commands into a heap. There is no checking of the length of
these inputs. Depending on the input, this will cause exploitable
condition.
 
We have confirmed the ability to execute our own code. This is a common
heap overflow vulnerability and can be exploited easily.
 
[Hervorhebung von mir] 

Der Satz "We chose not to provide detailed information about the location of the vulnerability and how to reproduce it because the author hasn't confirmed this vulnerability." findet sich in allen 3 Advisories, ebenso übrigens wie "We have confirmed the ability to execute our own code." Genau - auch in denen, die DoS-Schwachstellen betreffen. OK, das kann ein Copy&Paste-Fehler sein, oder man hat das erste Advisory als Vorlage genommen und den Satz nicht gelöscht. Interessanter ist aber die fehlende Angabe von Details, weil der Entwickler die Schwachstelle nicht bestätigt hat. Prima: Man behauptet, eine Schwachstelle gefunden zu haben, liefert aber keine weiteren Details und gibt selbst zu, dass der Entwickler die Schwachstelle nicht bestätigt hat. In diesem Fall gehe zumindest ich davon aus, dass die Schwachstellen wahrscheinlich nicht existieren.

Nach all diesen Schwachstellen oder Nicht-Schwachstellen zu existierenden Programmen fehlt nur noch ein Advisory zu einem nicht existierenden Programm. Wie wäre es mit einem Advisory zu Windows 8? Bitte sehr, damit kann ich sogar persönlich dienen:

Eine kritische Schwachstelle in Windows 8!

Eine Pufferüberlaufschwachstelle in Windows 8 erlaubt entfernten Angreifern die Ausführung beliebigen Codes durch das Senden bestimmter, präparierter TCP-Pakete. Details verrate ich nicht, weil Microsoft die Schwachstelle noch nicht bestätigt hat. Ich gehe sogar noch weiter: Aus Sicherheitsgründen habe ich noch nicht mal nach der Schwachstelle gesucht. Woher ich dann weiß, dass sie da ist? Ich weiß es einfach, das muss als Begründung genügen. Oder kann irgend jemand das Gegenteil beweisen?

Mit so einem Advisory würde ich sogar mit Sicherheit ins Schwarze treffen: Irgendwann wird Microsoft schon eine Schwachstelle beheben, auf die die Beschreibung passt. Das einzige, was mir einen Strich durch die Rechnung machen könnte, wäre Microsofts Namenswahl für die nächste Windows-Version. Wenn ich es mir so recht überlege: Vergessen wir die 8, machen wir eine 7 draus. Möchte jemand wetten, das es keine Schwachstelle in Windows 7 gibt, auf die die Beschreibung zutrifft?

Fazit

Die Bewertung von neu gemeldeten Schwachstellen ist schwierig: Manche sind laut Hersteller gar keine, machen das System aber eindeutig angreifbar und sollten deshalb auch als Schwachstelle betrachtet werden. Andere, von deren Vorhandensein man ausgehen kann, sind vielleicht bereits schon länger bekannt oder sogar bereits behoben, ohne das man das prüfen kann. Wieder andere werden ohne jede Nennung von nachvollziehbaren Details behauptet. Was macht man damit?

Im Fall der IIS-Schwachstelle, Pardon, Inkonsistenz, wäre die Durchführung der Workarounds (Heraufladen von Dateien nur durch vertrauenswürdige Benutzer und/oder Entfernen der "execute"-Berechtigung für Verzeichnisse mit heraufgeladenen Dateien) genau die richtige Reaktion: Egal ob Schwachstelle oder nicht, sie verhinderten Angriffe. Im Fall von MySQL und Suns Web Server 7 kann man nichts machen - ob und wenn ja welche Workarounds möglich sind, kann man nicht prüfen. Bei den Media Playern kann man auf das Öffnen von fragwürdigen Dateien verzichten. Ist das praktikabel? Für Skin- und Projektdateien geht das natürlich, aber was ist mit der angeblichen Schwachstelle im n.player? Den sollte man dann wohl besser gar nicht mehr verwenden, schließlich weiss man nicht, woher die ominösen überlangen Eingaben kommen können. Sollte man auf seinen gewohnten Media Player verzichten, weil jemand behauptet, eine Schwachstelle gefunden zu haben, die der Entwickler aber nicht nachvollziehen kann? Und welche Alternativen hätte man? Auch andere Media Player haben Schwachstellen, und vielleicht gerät man vom Regen in die Traufe, weil man einen wählt, der noch viel schlimmere Schwachstellen hat, die womöglich auch noch gerade ausgenutzt werden. Und das nur aufgrund einer Behauptung? Das sollte man sich gut überlegen.