Sicher mit Speicherüberläufen experimentieren

B

bluez

0
Hey,

irgendwie will dieses Thema in keines der Foren posten, aber weil es im Grunde ums Programmieren geht, schreibe ich hier.

Ich möchte mich endlich, endlich mit hardwarenaher Programmierung und deren Eigenheiten beschäftigen. Insbesondere will ich ein wenig mit allen Formen von Speicherüberläufen experimentieren. Dabei will ich mir natürlich mein bestehendes System weder ruinieren noch Sicherheitslücken darin aufreißen.
Die naheliegendste Option wäre eine virtuelle Maschine. Dann dachte ich aber daran, dass sich auch die virteulle Maschine nur die Register, Caches und den Arbeitsspeicher mit dem Gastsystem teilt. Im schlimmsten Fall würde mein Überlauf also mitten in einen Speicherbereich eines Programmes auf dem Gastgebersystem geschrieben, oder?

Wenn ich mir das so richtig gedacht habe: Wie kann ich das verhindern? Idealerweise mit einer VM. Ich möchte nur ungern von einer Live-CD aus arbeiten und auch nicht ein extra System dafür aufsetzen, da ich idealerweise auf dem Gastgebersystem der VM Multimedia laufen lassen und eine Internetverbindung offen halten will.
 
Mit Gastsystem meinst du den Host/Gastgeber, oder?

Prinzipiell dürfte da nichts passieren, es sei denn, du deckst mit deinen Experimenten eine bisher ungefixte Lücke in der VM-Software auf.
 
Jep, meine ich.

Ich rede aber nicht von regulär zugewiesenen Bereichen, sondern von absichtlich herbeigeführten Speicherüberläufen und der Manipulation der Speicherbereiche in die der Überlauf kommt, bzw. direkte Ausführungsstackmanipulation. Davon würde die Virtualisierungssoftware doch gar nichts merken, wenn der Überlauf in einen nichtzugewiesenen Bereich hinein erfolgt. Idealerweise merkt ein Betriebssystem was davon, aber darauf würde ich mich ungern verlassen müssen.

Vielleicht verstehe ich das auch einfach nur alles falsch, Ahnung hab ich nicht davon, sonst würde ich ja nicht damit experimentieren wollen :)

EDIT: So. Nach längerem Nachdenken, hab endlich sogar ich begriffen, warum du Probleme mit meiner Ausdrucksweise hattest :D Ich editiere das mal Zwecks besserer Verständlichkeit.
 
In einer VM wird der Speicher so gehandhabt, als sei der zugewiesene Speicher das Hardware-Maximum, das der virtuelle Rechner zu bieten hat. Sie hat einfach hinter den höheren Adressen keinen Speicher mehr, der beschreibbar sein könnte. Ausserhalb dieses Bereichs kannst du daher nicht schreiben, selbst mit einem BO nicht, es sei denn du verursachts den BO direkt in der VM-Software bzw. ihrem Virtualisierungslayer. Von daher sind VMs durchaus dazu geeignet BOs auf Applikationsebene (d.h. im User-Space) zu untersuchen.
 
Aber es wird doch nicht so sein, dass die Trennung der Adressen nicht auch einer physikalischen Trennung entspricht. Es wird doch eher sein, dass, kurz, Adressen A und C dem Host gehören und B und D dem Gast. Ein Betriebssystem ist doch nicht darauf ausgerichtet, dass es Lücken in den Adressen zulässt? Oder kriegt das Gastsystem auch emulierte Adressen, die dann aus seiner Sicht aufeinanderfolgen, auch wenn sie im physikalischen Speicher nicht nebeneinander liegen?
 
bluez hat gesagt.:
Oder kriegt das Gastsystem auch emulierte Adressen, die dann aus seiner Sicht aufeinanderfolgen, auch wenn sie im physikalischen Speicher nicht nebeneinander liegen?
Zum Vergrößern anklicken....

Die VM läuft als Programm unter dem Host (dem richtigen Betriebssystem), die Speicherverwaltungzuweisung erfolgt also wie bei anderen Programmen auch.

Dem Gast (dem Betriebssystem in der VM) weist der Hypervisor aus der Virtualisierungssoftware den eingestellten Arbeitsspeicher zu und "übersetzt" so den benötigten "echten" Arbeitsspeicher in die VM, so dass es für den Gast aussieht, als wäre es der pysikalischer, zusammenhängender Speicher.
 
bluez hat gesagt.:
Aber es wird doch nicht so sein, dass die Trennung der Adressen nicht auch einer physikalischen Trennung entspricht.
Zum Vergrößern anklicken....
Das ist auch ganz ohne Emulation nicht anders. Prinzipiell teilt man den phys. Speicher in Blöcke "Pages" auf. 4096 Bytes wäre z.B eine "gute" Zahl. Ein Programm hat erstmal virtuellen Speicheradressblock, der absolut nichts mit dem tatsächlichen physikalischen Speicher zu tun hat. Es geht sogar soweit, dass 0-Byte-initialisierte Speicheranforderungen (calloc bzw "VirtualAllocEx") vom OS einfach "abgenickt" werden ("hier hast du mal eine Adresse"), ohne dass tatsächlich kompletter Speicherblock dafür reserviert wird.
Erst bei einem Zugriff wird der "virtueller" Page eine physikalische Entsprechung zugeteilt.
Es kann also durchaus sein, dass der Speicherblock im Programm
0x400000 bis 0x450000 quer im RAM verteilt ist, einige Blöcke gar nicht "existieren" (bzw nur als Vermerk) und ein paar im Swap liegen. Und vor allem würde es nichts bringen, da irgendwas kontinuierlich draufschreiben zu können, da man immer noch absolut keine Ahnung hat, welcher Block jetzt welche Entsprechung hat (Code im Treiber oder Inhalt im Texteditor).
Weitere Stichworte wären "kernel space" "user spcae memory", "memory virtualization".

Btw: die Möglichkeit, vom Guest aus auf beliebigen/angrenzenden RAM des Hosts zu schreiben wäre eine mögliche, kritische Lücke. Insofern nicht zu 100% ausschließbar, allerdings sehr unerwünscht für sicheren Betrieb von virtualisierten Lösungen (virt-Servern und ähnlichem) - deswegen wird schon darauf geachtet. Win 9.x hatte z.B es nicht so mit der Trennung des Speichers, weshalb es auch für seine Freezes und Crashs bekannt wurde :)
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben