Seite 3: Null-Zeiger

Inhaltsverzeichnis

Null-Zeiger

Ich muss nicht lange suchen, um bei Mark Dowds wegweisendem Paper Leveraging the ActionScript Virtual Machine zu landen, das genau dieses Problem als Beispiel anführt. Ich erinnere mich zwar noch an die Aufregung in der Security-Szene, als er diesen Exploit veröffentlichte – weiß aber nicht mehr so genau, um was es dabei ging. „Kann ich wieder an den Rechner?“ ertönt es aus dem Hintergrund. „Einen kleinen Moment noch. Ich muss das hier nur eben schnell noch zu Ende bringen. Bin fast fertig.“

Zurück zu Dowds Flash-Exploit: Adobes Flash-Implementierung verwendet SceneCount, um Speicher zu reservieren. Damit da kein Unsinn passiert, führen sie davor Checks durch. Allerdings benutzt Adobe dafür einen vorzeichenbehafteten Vergleich „größer als“. Und weil beim EncodedU32-Wert 0x84039a19 das höchste Bit – das „Vorzeichen-Bit“ – gesetzt ist, ergibt der eine negative Zahl.

Das Resultat: Der Check funktioniert nicht wie geplant und der Flash-Interpreter versucht, mit dem Wert aus SceneCount Speicher zu reservieren – was natürlich fehlschlägt. Das Programm bemerkt das jedoch nicht und benutzt den NULL-Zeiger, der den Fehler signalisieren soll, trotzdem: Bumm!

Doch ganz so einfach ist es dann doch wieder nicht. Denn lange Zeit dachte man, so ein Fehler führte lediglich zum Programmabsturz und ließe sich nicht ausnutzen, um kontrolliert eingeschleusten Code auszuführen. Mark Dowd bewies jedoch an diesem Beispiel, dass das sehr wohl möglich ist. Grob vereinfacht funktioniert das so, dass der Flash-Interpreter etwas später an die Adresse 0+SceneCount einen Wert schreibt, den der Angreifer kontrolliert. Kombiniert mit dem bösartigen ActionScript-Bytestream kann er dann einen Adresszeiger für einen Sprungbefehl mit einem passenden SceneCount-Wert so überschreiben, dass sein eingeschleuster Code aktiviert wird.

Derartige Sicherheitsprobleme werden im Rahmen von normalen Stabilitätstests kaum gefunden. Der Entwickler befindet sich in einer ähnlichen Situation wie ein Ingenieur, der die Tragfähigkeit einer Brücke berechnet und zu dem Schluss kommt, dass sie problemlos hundert Leute aushalten sollte. Er hat dabei jedoch nicht bedacht, dass auch 100 Soldaten so im Gleichschritt über die Brücke marschieren könnten, dass sie dabei die Resonanzfrequenz der Brücke treffen. Die Erschütterungen schaukeln sich dann immer weiter auf, bis die Brücke schließlich einstürzt. Solche Resonanzkatastrophen haben tatsächlich im 19. Jahrhundert in England und Frankreich zum Einsturz zweier Brücken geführt und dabei viele Opfer gefordert.

Genau genommen ist die Situation für Software-Entwickler sogar noch schwieriger: Sie müssen nämlich davon ausgehen, dass die „bösen Jungs“ absichtlich im Gleichtakt springen – und zwar so lange, bis sie die kritische Frequenz finden. Dann machen sie so lange weiter, bis sie die Brücke zum Einsturz bringen oder, um das Bild zu verlassen: bis sie mit einem speziell präparierten Filmchen den Flash-Interpreter dazu bringen, eingebetteten Code anzuspringen und auszuführen.

Apropos Code – das erinnert mich an das Tag DEFINEBITSJPEG, in dem sich der Verweis auf urlmon.dll, die URL und der komische Dateiname befinden.