C
DEvent schrieb:
geeky schrieb:
http://www.heise.de/newsticker/meldung/64624
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).
