Huhn oder Ei? Patch oder Exploit?
Marc Ruef | 05.01.2009

Ich bin nie darum verlegen, mich in Gedanken mit einem guten Rätsel aufzuhalten. Umso mehr machen mir jene Gedankenspiele Spass, die keine echte Lösung zulassen. Also ein philosophischer Koan, der quasi den Fragesteller und den Denker gleichermassen sich selbst relativieren lässt. Wenn ein Baum im Wald umfällt und es ist niemand da, macht der umfallende Baum dann dennoch ein Geräusch? Was war zuerst da, das Huhn oder das Ei?

Vor einiger Zeit machten David Brumley und Pongsin Poosankam von der Carnegie Mellon School of Computer Science, Dawn Song von der University of California, Berkeley und Jiang Zheng von University of Pittsburgh von sich reden. Sie gingen in ihrer Arbeit Automatic Patch-Based Exploit Generation (http://www.cs.cmu.edu/~dbrumley/pubs/apeg.html) der Frage nach, ob und inwiefern sich aus einem Patch automatisiert entsprechende Exploits generieren lassen.

Nun, einige wissen es schon längst, doch wahrhaftig waren und sind Patches seit jeher eine ausgezeichnete Quelle, um sich über eine Schwachstelle schlau zu machen. Ganz besonders Beliebt im Unix-Umfeld sind die Diff-Files, mit denen sich bestehende Quellen automatisiert anpassen lassen. Durch das Entfernen, Ersetzen und Hinzufügen neuer Codezeilen wird der alte Quelltext auf den neuesten Stand gebracht und damit das Problem aus der Welt geschafft.

Derjenige, der diesen Prozess versteht, kann durch einfachstes Reverse Engineering die ursprünglichen Fehlerquellen eruieren. Das Umsetzen eines Exploits zur Ausnutzung der Schwachstelle ist damit nur noch ein bisschen Fleissarbeit, die jeder Programmierer mit einem grundlegenden Interesse an angewandter Computersicherheit für sich erschliessen kann.

In manchen Bereichen, gerade im Windows-Umfeld, wird jedoch mit Binaries zur Applizierung von Patches gearbeitet. Es wird also nicht mehr der Quelltext der Software auf dem Zielsystem angepasst, sondern die betroffenen Komponenten (z.B. EXE-Dateien oder DLL-Bibliotheken) direkt mit den angepassten Versionen überschrieben. Dieser Prozess passiert für den Endanwender weitestgehend intransparent. Er weiss auf Anhieb nicht, welche Elemente entfernt, ausgetauscht oder verändert wurden.

Zu Anfangszeiten war es besonders beliebt während des Patching-Prozesses durch File-Monitoring die Zugriffe auf dem Dateisystem zu beobachten sowie die entsprechenden Anpassungen in der Registry zu protokollieren. Dadurch können die betroffenen Komponenten ausgemacht und Hinweise auf etwaige Fehlerquellen gesammelt werden. Dass beim Microsoft Security Bulletin MS04-028: Buffer Overrun in JPEG Processing (http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx) eine Ersetzung von gdiplus.dll vorgesehen war, rückte die Datei unerweigerlich in den Mittelpunkt des Interesses (ein Exploit war jedoch in diesem Fall schon lange vor dem Microsoft-Patch verfügbar (http://www.scip.ch/cgi-bin/smss/showadvf.pl?id=833)).

Jenachdem kann durch die Namensgebung einer betroffenen Komponente die Ursache für ein Problem ausgemacht werden. Durch weiterführendes Reversing des Binaries lassen sich mit zusätzlichen Aufwand die exakten Bereiche determinieren. Hexeditoren und Disassembler helfen dabei, sich dieser Aufgabe anzunehmen. Sehr wohl lässt sich damit exakt bestimmen, wie das Problem zustande kommt und wie man es ausnutzen kann. Es gibt eine Reihe von Leuten, die sich auf solche Analysen spezialisiert haben. Und dies mit nicht zu unterschätzendem Erfolg.

Ein Tool, welches nun die Differenzen, welche von Patches herbeigeführt werden, analysieren und sodann einen entsprechenden Exploit generieren kann, wäre ein sehr mächtiges Werkzeug. Einerseits für die vielen Auditoren, die mit einer Unmenge an schlecht dokumentierten Schwachstellen zurecht kommen müssen (in den letzten Jahren hat sich der Trend entwickelt, sehr wenige Details den Advisories mitzugeben). Andererseits aber ebenfalls die unbekannte Anzahl an Blackhats, die die Schwachstellen ausschliesslich zu ihrem eigenen Vorteil nutzen wollen.

Spontan würde man die Frage danach, ob der Exploit oder der Patch zuerst existiert hat, jeweils mit dem Exploit beantworten. Schliesslich muss ja nur das gepatcht werden, was zu einem Problem wird (siehe Tractatus 3.3.2.1.1.* (http://www.computec.ch/projekte/tractatus/?s=tractatus&m=liste&h=3.3.2.1.1&l=6)). Doch unter dem soeben gezeigten Betrachtungswinkel sollte klar werden, dass sich gewisse Exploits auch erst durch die jeweiligen Patches (für "jedermann") generieren lassen. Die Hersteller hieven mit einem Patch die Angreifer damit quasi auf die Bühne der Exploit-Entwicklung. Ein Teufelskreis, dem man nicht entrinnen kann. Nur halt damit, dass man von Anfang an gute Software schreibt. Und wie wir alle wissen, bleibt dies wohl auch weiterhin ein Ding der Unmöglichkeit.