Ich habe versucht, Aleph One's Beispiel auszuführen, um eine BOF zu bekommen und eine Shell zu öffnen.
Dies ist Aleph One Papier: Ссылка
Und das ist der einfache C-Code (fast auf der Hälfte des Papiers):
%Vor%Nun habe ich versucht, dieses Programm in einer SSH-Bash auszuführen, aber ohne Erfolg.
Da nach dem Ausführen nichts passiert ist, rate ich, dass ich gerade die Rückkehradresse nicht geschrieben habe, also benutzte ich GDB, um den Versatz zwischen der ret-Variable und der realen Rückkehradresse zu sehen, und erkannte, dass es 7 war.
Um mich selbst zu überprüfen, habe ich versucht, ret in 3,4,5,6 zu erhöhen, und tatsächlich, nur wenn ich Zeile 10 zu:
änderte %Vor%Ich habe einen Segmentierungsfehler bekommen.
Aber ich verstehe nicht, warum eine Bash nicht geöffnet ist, und ich bekomme stattdessen diesen Fehler.
PS Ich lief auf 'logic smashtheshack' SSH Servern (welche eine ihrer Herausforderungen ist BOF): Ссылка
Danke für die Helfer.
Von Ссылка :
Dieser Stub ist eine aktualisierte Version des klassischen Shellcode-Test-Stubs, mit einem Hauptunterschied: Im neuen Stub ist der Shellcode zur Kompilierungszeit #definiert, so dass er direkt vom gcc-Präprozessor in die Hauptroutine platziert werden kann.
Dies ist notwendig, weil Linux und GCC im Laufe der Zeit viel vorsichtiger geworden sind, welche Abschnitte einer ausführbaren Datei ausführbaren Code enthalten können (im Gegensatz zu nicht ausführbaren Variablen). Die traditionelle Version des Programms funktioniert nicht mit neueren Versionen von Linux:
Der klassische shellcode c stub erzeugt auf neueren Systemen einen segfault weil das Shellcode [] - Zeichenarray explizit gespeichert wird nicht ausführbarer .rodata-Abschnitt der ELF-Datei. Wenn der Computer das nicht ausführbare Array als Funktion neu formatiert und versucht, es auszuführen, das Programm stürzt ab
. Beachten Sie auch diese Änderungen beim Schreiben von Shellcode:
%Vor%Das Problem liegt im Shellcode. Der Shellcode ist eine Const-Zeichenfolge und kann daher nicht geändert werden. Wenn Sie sich die Disassemblierung des Shellcodes ansehen, können Sie sehen, dass der Code versucht, die Zeichenfolge zu ändern.
Sie könnten versuchen, Speicher zuzuordnen und den Shellcode dort zuzuweisen. Funktioniert möglicherweise immer noch nicht, abhängig vom Betriebssystem, da Sie möglicherweise die Schutzeinstellungen ändern müssen, damit der Code im zugewiesenen Speicherblock ausgeführt werden kann.
Grund für die Eigenänderung ist, dass der Schritt zum Ausführen der Shell am Ende ein 0 Byte benötigt, aber dies kann nicht in der Zeichenkette enthalten sein, also muss der Code ihn patchen, bevor er die Shell ausführen kann. Dies ist der Grund für die SIGSEGV.
Ihr Problem ist fast identisch mit diesem: Assembly-Code zeigt weiterhin Segmentfehler an
Der Shellcode ist im Grunde gleich. Nicht genau, aber nach dem gleichen Prinzip.
Aktualisieren
Um dies ein wenig besser zu erklären, wird der Exploit funktionieren, wenn das BSS-Segment beschreibbar ist. Die Deklaration eines solchen Strings macht es nach dem C-Standard const. Das Schreiben in eine statische Zeichenfolge ist ein nicht definiertes Verhalten und kann daher funktionieren.
Tags und Links c security buffer-overflow shellcode