Schadcode in Ani-Datei
-
Hi
es kennen ja bereits viele den Virus der sich in der .ani Datei versteckt, hier ein lustiges Video für Vista:
http://www.youtube.com/watch?v=hf0S0Vk7j6IIch würde wirklich gerne wissen wie das überhaupt möglich ist? Ich kenne das Format der .ani Dateien von MS nicht, aber ich denke mal es ist wie eine .gif Datei mit Animationen. Also einfach mehere bmps in einer Datei verpakt, die vllt. noch timer-Informationen enthält. Aber wieso wird da irgendwelcher Code ausgeführt wenn der Explorer die .ani einließt? Bei einer bmp oder jpeg Bildbetrachter wird doch auch nicht die Bilddaten als Ausführbar betrachtet? Nützt man vielleicht Besonderheiten beim Auslesen der Datei aus, dass das Format der Datei nicht korrekt ist und es dadurch zur Bufferoverflow oder sowas kommt? Aber selbst wenn das Format nicht korrekt ist, wieso gibt's nicht einfache Sicherheitschecks für das Format der Datei?
Normalweise steht in einem Info-Block die genaue Größe der Daten, und wenn dann darin was falsches steht, dann ließt man halt die Datei ein bis ein EndOfFile kommt. Dann wird abgebrochen und eine Fehlermeldung "Die Datei ist keine .ani Datei" ausgegeben.
Ich würde einfach gerne wissen wie das technisch überhaupt möglich ist über eine Bilddatei Code einzuchleußen in einen Bildbetrachter, so das der Code auch ausgeführt wird.
Man kann ja das Header einer Jpeg nehmen und in den Daten-Bereich keine komprimierten Bilddaten sondern Codedaten reinschreiben. Dann würde aber der Dekomprimierer des Bildbetrachters einfach einen Fehler melden, das die Daten nicht im richtigem Format vorliegen. Aber er würde doch die Daten nicht Ausführen?
-
DEvent schrieb:
Nützt man vielleicht Besonderheiten beim Auslesen der Datei aus, dass das Format der Datei nicht korrekt ist und es dadurch zur Bufferoverflow oder sowas kommt?
Genau so ist es.
DEvent schrieb:
Aber selbst wenn das Format nicht korrekt ist, wieso gibt's nicht einfache Sicherheitschecks für das Format der Datei?
Normalweise steht in einem Info-Block die genaue Größe der Daten, und wenn dann darin was falsches steht, dann ließt man halt die Datei ein bis ein EndOfFile kommt. Dann wird abgebrochen und eine Fehlermeldung "Die Datei ist keine .ani Datei" ausgegeben.Nicht alle Overflows entstehen, weil irgendwo steht "Jetzt kommen 20 Bytes", es kommen aber 25. (Obwohl das auch schon vorkam.) Z.B. gerade bei gepackten Bildern gibt es ja Metadaten wie: "Jetzt die nächsten X Pixel weiß malen". Wenn der Programmierer seine Hausaufgaben nicht gemacht hat, übergibt man eben mal 150 Pixel. Dem Programm wurde aber im Header gesagt, das Bild sei 10x10 Pixel groß, und entsprechend viel Speicher hat sich Programm dafür auch nur vorbereitet.
Siehste, wieder Platz für eine "einfache Sicherheitsabfrage". Und das stell dir jetzt belibig oft vor. Es ist nicht die Kompliziertheit, sondern die Masse.DEvent schrieb:
Ich würde einfach gerne wissen wie das technisch überhaupt möglich ist über eine Bilddatei Code einzuchleußen in einen Bildbetrachter, so das der Code auch ausgeführt wird.
Komisch, weil gerade diese Sache ab Vista auf 64Bit der Vergangenheit angehören sollte. (No Execution Flag)
-
-
geeky schrieb:
Das ist ja eigenartig, ich dachte die modernen Systeme haben einen virtuellen Speicher pro Programm/Thread. Also jedes Programm sieht nur den Speicher von 0x0000 bis 0xFFFF, der halt virtuell ist und im Grunde dann an der Stelle 0x34A93498 bis 0xA0FF0A00 geht. Das Betriebsystem kümmert sich dann daram das kein Programm in den Speicher eines anderen Programmes schreiben kann.
Problem ist dann mit den shared-Libs, deren Codebereich muss dann aber doch von jedem Programm sichtbar sein, das die Lib benutzt.
Ich war sowieso erstaunt das man API-Funktionen hat die es einem erlauben in den Codebereich eines anderen Programms Code einzuschleußen. Der Codebereich eines anderen Programms müsste eigentlich sowas wie heiliger Boden sein, auf dem jeder Eindringling sofort erschoßen wird. Überhaupt sollte der Codebereich eines Programmes nur von System sichtbar sein, und man sollte nur betteln können, das man einen ganz bestimmten Bereich davon sichtbar ist. Überhaupt sollte doch das Host-Programm erst erfragt werden, ob es das überhaupt erlaubt. Aber nein, nichts dergleichen, einfach eine API-Funktion aufrufen und schon kann man Code im Speicherbereich eines x-beliebigen Programmes ausführen. Das müsste doch schon vorher klar sein das sowas ein rießiger Sicherheitsloch ist.
Da sind die ganz neuen Systeme per Design (diesmal richtig) dagegen geschützt. Man vereinbart einfach Protokolle zwischen den Programmen und auch zwischen Bibliothek/Programm. Die Protokolle bestehen im Grunde aus Text-Anfragen und Text-Ergebnis. Es wird niemals der Speicherbereich eines anderen Programm/Bibliothek sichtbar. Falls ein Programm versucht über seinen Adressraum zu lesen/schreiben wird einfach ein Laufzeitfehler verursacht, der das Programm beendet.
Z.b. der X-Server ist ein Beispiel dafür. Der X-Server kommuniziert ja mit dem Kernel durch das TCP/IP-Protokoll. Genauso wie der SQL-Server. Sowas könnte man für das gesammte System bauen.
-
DEvent schrieb:
geeky schrieb:
Das ist ja eigenartig, ich dachte die modernen Systeme haben einen virtuellen Speicher pro Programm/Thread. Also jedes Programm sieht nur den Speicher von 0x0000 bis 0xFFFF, der halt virtuell ist und im Grunde dann an der Stelle 0x34A93498 bis 0xA0FF0A00 geht. Das Betriebsystem kümmert sich dann daram das kein Programm in den Speicher eines anderen Programmes schreiben kann..
Das hat mit diesem Problem nichts zu tun, das Exploit setzt an anderer Stelle an: Die Rücksprungadressen liegen bei der x86-Architektur auf dem Stack, auf dem auch die lokalen Variablen liegen. Der Stack wächst zudem in Richtung kleinerer Adressen, das heißt die Rücksprungadresse liegt "hinter" den den lokalen Variablen. Wenn dann ein lokaler Puffer überläuft, wird diese Adresse überschrieben und das nächste "return" springt an eine völlig andere Stelle als geplant, z.B. (ganz naiv) in eine Funktion wie unlink().
Das noexecute-flag spielt hier keine Rolle, weil im Stack kein Code ausgeführt wird.
Programme *völlig* trennen wird auch ziemlich schwer, wenn das System benutzbar bleiben soll. Debugger sind zum Beispiel eine Klasse von Programmen, die zwangsläufig im Speicher fremder Prozesse herumschreiben müssen (und zwar nicht nur von Prozessen, die vom Debugger selbst gestartet wurden).
