Wie testet man eigentlich Patches? Woher bekommt man die nötigen Informationen? Ist Full Disclosure besser als Responsible Disclosure? Dieser Standpunkt Sicherheit liefert die Antworten.

Der Patch ist weg, der Patch ist da, ...

Microsoft hat am vorigen Dienstag das in der Vorwoche zurückgezogene Update zum Security Bulletin MS10-025 in einer (hoffentlich) fehlerfreien Version erneut veröffentlicht. Benutzer von Windows 2000 Server SP4, die die Windows Media Services aktiviert haben, können die kritische Schwachstelle darin nun also beheben. Wirklich? Immerhin hat Microsoft das ja schon am regulären Patchday behauptet, und dann hieß es plötzlich "April April, der Patch macht nicht, was er soll". Wie erkennt man, ob die Schwachstelle diesmal richtig behoben wurde oder nicht? Bzw. allgemeiner gefragt: Wie erkennt man, ob irgend eine Schwachstelle wie vom Hersteller behauptet behoben wurde oder nicht? Und dabei muss das "oder nicht" gar nicht mal durch einen Fehler des Herstellers passieren, es könnte ja auch sein, dass der Patch aus welchen Gründen auch immer auf dem eigenen System nicht richtig installiert wurde.

Patch da, Schwachstelle weg?

Was passiert denn, wenn ein Patch wie behauptet funktioniert? Die Schwachstelle ist nicht mehr vorhanden, ein Exploit dafür funktioniert also nicht mehr. Gut, wenn man einen Exploit zur Hand hat, mit dem man sein gepatchtes System testen kann. Häufig werden in Advisories Proof of Concepts oder vollständige Exploits mitgeliefert, mit denen sich eine Schwachstelle nachvollziehen lässt. Damit lässt sich natürlich auch der Patch testen: Funktioniert der Exploit nicht, hat der Patch funktioniert. Zumindest teilweise, evtl. wurde auch nur ein Angriffsvektor statt der eigentlichen Schwachstelle behoben, aber dazu komme ich gleich noch. Im Fall des Security Bulletin MS10-025 wurde vom Entdecker der Schwachstelle, Fabien Perigaud von CERT-LEXSI, im eigenen Advisory kein Exploit veröffentlicht, man kann die Schwachstelle also nicht damit testen. Allerdings gibt es für das Metasploit-Framework bereits ein Modul, so dass der Patch damit getestet werden kann.

"Do it yourself"

Gibt es keinen Proof of Concept oder Exploit, kann man nur versuchen, aus den verfügbaren Informationen einen Test zu entwickeln. Im Fall von Directory-Traversal-, File-Inclusion-, SQL-Injection- und Cross-Site-Scripting-Schwachstellen in Webanwendungen reicht es i.A. aus, wenn man das betroffene Skript und den betroffenen Parameter kennt, um dann mit einigen Testmustern das Vorhandensein einer Schwachstelle (bzw. beim Test eines Patches deren Fehlen) zu prüfen. Bei komplexeren Schwachstellen ist das aber nicht so einfach, vor allem, wenn man nur weiß, das es z.B. in einer bestimmten Funktion oder einem bestimmten Service einen Pufferüberlauf gibt. Man kann zwar z.B. mit Fuzzing verschiedene Eingaben erzeugen und gucken, ob eine davon einen Pufferüberlauf auslöst, aber das hilft nicht wirklich weiter: Findet man einen Pufferüberlauf, weiß man nicht, ob man die angeblich behobene Schwachstelle oder eine neue entdeckt hat. Findet man keinen Pufferüberlauf, hat man vielleicht nicht die richtige Eingabe erzeugt.

Angriffsvektoren statt Schwachstellen

Carsten Eiram von Secunia hat einen sehr interessanten Blogeintrag zum Thema Angriffsvektoren und Schwachstellen geschrieben. Während er auf die Probleme eingeht, die durch das Melden vieler Angriffsvektoren als separate Schwachstellen entstehen, gehe ich mal von einem anderen Gesichtspunkt aus: Es ist bereits öfter vorgekommen, das ein Hersteller nur einen Angriffsvektor behoben hat, die eigentliche Schwachstelle aber bestehen blieb. In so einem Fall helfen Tests mit veröffentlichten Exploits nicht weiter, die scheitern dann nicht an der Schwachstelle, sondern am behobenen Angriffsvektor. In der Hinsicht muss man sich also auf den jeweiligen Hersteller verlassen.

Full Disclosure und Responsible Disclosure

Die Diskussion Pro und Contra Full Disclosure dürfte ungefähr genau so alt wie der erste Bug sein. Es gibt für beide Ansätze gute und schlechte Argumente, und ich persönlich tendiere eher zur "Full Disclosure", auf jeden Fall, wenn der Entdecker einer Schwachstelle den Hersteller vorher informiert hat und der nicht angemessen reagiert. Und das u.a. aus folgenden Gründen:

1. Die im Rahmen der "Operation Aurora" für den Angriff auf Google ausgenutzte Schwachstelle im IE war Microsoft schon vor dem Angriff im Rahmen der Responsible Disclosure gemeldet worden. Wäre die Schwachstelle öffentlich bekannt gewesen, hätte man sich evtl. mittels Workarounds vor dem Angriff schützen können, und Virenscanner hätten eine Signatur gegen den Exploit enthalten können. Responsible Disclosure verhindert nicht, das Cyberkriminelle die Schwachstelle selbst entdecken und ausnutzen.
2. Oft werden Schwachstellen, die vor ihrer Veröffentlichung noch auf die lange Bank geschoben werden sollten oder sogar schon geschoben wurden, danach sehr schnell behoben, siehe z.B. aktuell die Schwachstelle im Java Deployment Toolkit.
3. Nur, wenn eine Schwachstelle genau bekannt ist, kann man sie nachvollziehen und einen veröffentlichten Patch prüfen. Dass das notwendig ist, hat Microsoft ja gerade bewiesen.

Außerdem schließen sich Full Disclosure und Responsible Disclosure nicht zwingend aus: Was spricht dagegen, einen Hersteller im Rahmen der Responsible Disclosure über eine gefundene Schwachstelle zu informieren, einige Zeit (die nicht zu lang sein sollte) nach dem Veröffentlichen eines Patches oder Updates aber im Rahmen einer "Responsible Full Disclosure" alle Details zu veröffentlichen, so dass der Patch geprüft werden kann? Weil die Cyberkriminellen dann einen Exploit entwickeln können? Die, die es wirklich darauf anlegen, haben den Patch wenige Stunden nach dessen Veröffentlichung analysiert und einen Exploit fertig - früher auch als "Exploit Wednesday" nach dem Patch-Tuesday bekannt.

Verizon schreit nach einem Flame-War

Wade Baker von Verizon fordert im dortigen Security Blog eine Neudefinition des Begriffs "Security Researcher":

"Security Researcher: One who studies how to secure things and/or how things are not secure in order to find a solution.
Security Practitioner: One who applies the findings of the Security Researcher in order to make things more secure.
Narcissistic Vulnerability Pimp: One who – solely for the purpose of self-glorification and self-gratification – harms business and society by irresponsibly disclosing information that makes things less secure (or increases risk).
Criminal: One who actively subverts security without authorization or deliberately creates ways for others to do so."

Interessante Idee. Betrachten wir mal die Schwachstelle im Java Deployment Toolkit. Die wollte Oracle auf die lange Bank schieben (OK, das ist Oracle, da ist sowas normal, die patchen halt nur einmal im Quartal und lassen ihre Kunden ansonsten im Regen stehen, bis denen das Wasser zum Hals steht), obwohl sie sich sehr leicht ausnutzen lässt. Dank Tavis Ormandys Veröffentlichung der Schwachstelle konnten die Benutzer sich z.B. durch Setzen des Killbits und Ändern der ACLs vor einem Angriff schützen. Damit ist Ormandy also ein verantwortungsvoller Security Researcher, da er sowohl die Schwachstelle gefunden als auch eine Lösung geliefert hat. Ja, diese Definition ist gut, damit bin ich einverstanden.

Aber was sind dann die Nichtstuer von Oracle? Die Beschreibung von "Criminal" würde passen, aber das ist doch etwas sehr hart. Da müssen wir wohl beim "Narcissistic Vulnerability Pimp" noch etwas nachbessern: Auch wer nichts tut, obwohl er von einer Schwachstelle weiß, gehört da rein. Ach, Baker hat das alles anders gemeint? Aber er schreibt doch "One is either part of the problem or part of the solution." Und Oracle war ja wohl eher Problem als Lösung, während Ormandy eine Lösung lieferte und dafür sorgte, das Oracle auch aufwachte, oder?

Übrigens hat Bruce Schneier schon 2007 eine passende Antwort auf Wade Bakers Text geschrieben: "Schneier: Full Disclosure of Security Vulnerabilities a 'Damned Good Idea'"

Carsten Eilers

zurück

nach oben

drucken

empfehlen

kommentieren