Frage:
ROP exploitation in x86_64 linux
user40387
2014-02-20 14:01:52 UTC
view on stackexchange narkive permalink

Ich arbeite an einer renditeorientierten Programmierausnutzung unter einem x86_64-Linux. Meine Forschung führt jedoch dazu, dass die ROP-Ausnutzung auf einem 64-Bit-Linux-Computer unmöglich ist, da alle Codesegmente in führenden Null-Byte-Adressen geladen sind. Stimmt das? 

  Gdb, Abschnitte: (gdb) i-Datei `/ home / ****** / Desktop / BOF / lib64 ', Dateityp elf64-x86-64. Einstieg: 0x400ffc 0x0000000000400190 - 0x00000000004001b0 ist .note.ABI-tag 0x00000000004001b0 - 0x00000000004001d4 ist .note.gnu.build-ID 0x00000000004001d8 - 0x00000000004002f8 ist .rela.plt 0x00000000004002f8 - 0x0000000000400312 ist .init 0x0000000000400320 - 0x00000000004003e0 ist .plt 0x00000000004003e0 - 0x0000000000494808 ist .text 0x0000000000494810 - 0x000000000049614c ist __libc_freeres_fn 0x0000000000496150 - 0x00000000004961f8 ist __libc_thread_freeres_fn 0x00000000004961f8 - 0x0000000000496201 .fini ist 0x0000000000496220 - 0x00000000004b6224 .rodata ist 0x00000000004b6228 - 0x00000000004b6230 ist __libc_atexit 0x00000000004b6230 - 0x00000000004b6288 ist __libc_subfreeres 0x00000000004b6288 - 0x00000000004b6290 ist __libc_thread_subfreeres 0x00000000004b6290 - 0x00000000004c32ac ist .eh_frame 0x00000000004c32ac - 0x00000000004c33b9 ist. gcc_except_table 0x00000000006c3ea0 - 0x00000000006c3ec0 ist .tdata 0x00000000006c3ec0 - 0x0000000 0006c3ef8 ist .tbss 0x00000000006c3ec0 - 0x00000000006c3ed0 .init_array 0x00000000006c3ed0 ist - 0x00000000006c3ee0 ist .fini_array 0x00000000006c3ee0 - 0x00000000006c3ee8 ist .jcr 0x00000000006c3f00 - 0x00000000006c3ff0 .data.rel.ro 0x00000000006c3ff0 ist - 0x00000000006c4000 ist .got 0x00000000006c4000 - 0x00000000006c4078 ist .got.plt 0x00000000006c4080 - 0x00000000006c56f0 ist .data 0x00000000006c5700 - 0x00000000006c8308 ist .bss 0x00000000006c8308 - 0x00000000006c8338 ist __libc_freeres_ptrs 0x0000000000400190 - 0x00000000004001b0 ist .note.0000000000004001b0 ist
0x00000000004001d8 - 0x00000000004002f8 ist .rela.plt 0x00000000004002f8 - 0x0000000000400312 0x0000000000400320 .init ist - 0x00000000004003e0 ist .plt 0x00000000004003e0 - 0x0000000000494808 .text 0x0000000000494810 ist - 0x000000000049614c ist __libc_freeres_fn 0x0000000000496150 - 0x00000000004961f8 ist __libc_thread_freeres_fn 0x00000000004961f8 - 0x0000000000496201 .fini ist 0x0000000000496220 - 0x00000000004b6224 ist .rodata 0x00000000004b6228 - 0x00000000004b6230 ist __libc_atexit 0x00000000004b6230 - 0x00000000004b6288 __libc_subfreeres ist 0x00000000004b6288 - 0x00000000004b6290 ist __libc_thread_subfreeres 0x00000000004b6290 - 0x00000000004c32ac ist .eh_frame 0x00000000004c32ac - 0x00000000004c33b9 ist .gcc_except_table 0x00000000006c3ea0 - 0x00000000006c3ec0 .tdata 0x00000000006c3ec0 ist - 0x00000000006c3ef8 ist .tbss 0x00000000006c3ec0 - 0x00000000006c3ed0 ist .init_array 0x00000000006c3ed0 - 0x00000000006c3ee0 .fini_array 0x0000000000 ist 6c3ee0 - 0x00000000006c3ee8 ist .jcr 0x00000000006c3f00 - 0x00000000006c3ff0 ist .data.rel.ro 0x00000000006c3ff0 - 0x00000000006c4000 ist .got 0x00000000006c4000 - 0x00000000006c4078 ist .got.plt 0x00000000006c4080 - 0x00000000006c56f0 .data ist 0x00000000006c5700 - 0x00000000006c8308 ist .bss 0x00000000006c8308 - 0x00000000006c8338 ist __libc_freeres_ptrs
Dies hängt von dem Fehler ab, den Sie ausnutzen. Du sprichst von einfachen strcpy / strcat / sprintf / ... Bugs, oder?
Ja, aber was ist der Unterschied? In allen Fehlern (wenn es kein Kuchen ist) haben wir Adressen wie oben ... siehe auch: http://v0ids3curity.blogspot.de/2013/07/some-gadget-sequence-for-x8664-rop.html (Ich kann nicht verstehen, wie wir ROP-Gadgets verwenden können, deren Adressen Null-Bytes enthalten.)
Sie können ROP-Gadgets mit Null-Bytes in den Adressen erstellen. Ja. In der Tat ist es eine Weile her, dass ich 0x00 Zeichen in meinen Exploit-Nutzdaten nicht herausfiltern muss, da es eine Weile her ist, dass ich kein reines Problem der String-Manipulation ausnutzen kann (d. H. Nur binäre Formate und so).
Einer antworten:
jbh
2014-02-20 19:50:04 UTC
view on stackexchange narkive permalink

Dies hängt von der Art des Fehlers ab, den Sie ausnutzen. Wenn Ihre Nutzdaten keine Null-Bytes enthalten können (ein anfälliger Strcpy), kann dies zu einem Problem werden, jedoch haben nicht alle Fehler diese Einschränkung. Nehmen wir zum Beispiel einen Fehler beim Analysieren eines Dateityps, der Null-Bytes zulässt.

Es besteht auch die Möglichkeit, dass eine Reihe von Fehlern verwendet werden, z. B. die Idee des Sprühens von Haufen. Im Allgemeinen sprühen Sie den Haufen mit anderen "legitimen" Dingen, wie in diesem Artikel von Corelancoder. Sein Shell-Code, der Ihre ROP-Kette wäre, besteht aus Teil-Bitmap-Dateien, die er nacheinander lädt, um "den Heap zu sprühen", während der Fehler tatsächlich durch Javascript ausgelöst wird und den Shellcode nicht enthält.

Wenn Sie nur an ROP arbeiten möchten und sich keine Gedanken über Byte-Einschränkungen machen möchten, würde ich empfehlen, ein einfaches Kabel zu schreiben, um Ihren Shellcode zu testen.

BEARBEITEN Entschuldigung, falsches Kabel. Dieser ist eindeutig 64-Bit-spezifisch. 

  #include <stdio.h> # include <stdlib.h>int data [10000000]; void start_rop (char * rop) {__asm ​​("mov (% rax) ,% rsp "); // Inhalt des ersten Arguments in den Stapelzeiger verschieben} int main (int argc, char * argv) {char code [] = "AAAAAAAA"; char * malloc_code = (char *) malloc (sizeof (code)); memcpy (malloc_code, &code, sizeof (code)); start_rop (malloc_code); frei (malloc_code); return 0;}
Ich denke, der obige Code hat nichts mit rop zu tun. Er ist nur eine C-Stub-Funktion zum Testen von Shellcodes und kann auch nicht für neue Kernel verwendet werden, da Datenabschnitte nicht mehr ausführbar sind.
Sie sind völlig richtig, ich habe über das falsche Geschirr kopiert. In Antwort behoben.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...