Предыстория: начал читать "Искусство взломи и защиты систем" (http://www.inattack.ru/program/678.html). Книга вроде как добротная. Решил пробовать описанные приемы на практике. Так вот ситуация такая - в статье "Проблемы адресации" (а если конкретно, то на странице 40) описывает метод с использованием NOP, где в атакующей программе берется свой (!!!) esp и забивает буфер (тот, что будет передаваться в атакуемую программу) этим адресом (причем до половины длины буфера) и только потом, ближе к середине буфера, начинает записывать шеллкод. Естестественно, как это часто бывает, данный прием на моей машине не работает (archlinux x86). Начал разбираться почему. Стал тыкать коредамп гдб, вобщем тот адрес возврата, который предлагался атакующей программой и близко не подходил мою область стека. Более того, команда Код (Text): (gdb) x 0xbfd3b428 0xbfd3b428: 0x00000000 показала, что адрес ссылается на нули. Ладно, стало любопытно, какой действительный адрес возврата лежит в этом стеке фрейма: блин, эти адреса даже близко не походят! Экспериментальным путем выяснил, что адрес стекового фрейма меняется от запуска к запуску, хотя в книге было написано "... потому что мы знаем, что во всех программах стек начинается с одного и того же адреса.". На ум приходит только мысль, что либо это предположение наивное, либо я чего-то недопонимаю... Прошу совета у бывалых, что я сделал не так? В аттаче эксплутируемая прога (victim.c) и эксплуатирующая (nopattack.c). Пользовать так: буду очень благодарен за помощью
хм, сегодня закомментировал последнюю строчку файла nopattack.c: Код (Text): system("/bin/bash"); и программа перестала вывалиться с сегфолтом. но, шелл не открывается, она просто завершается. копаю дальше. но от помощи не откажусь) UPD: не сегфолтится потому что в енваерменте нет такой переменной и, соответсвенно, аргумент равен нулю и программа корректно завершается. Ступил. Сорри.
milo Там же написано: Мол, нужно найти область в стеке, куда затолкается шелл-код. Искать будем методом тыка, но не совсем. Для отправной точки возьмем адрес начала стека из своей программы, т.к. он в системе условно одинаков для разных программ. Дальше идет длинный подбор смещений, когда на вход программы, внедряющей шелл-код подаются разные числа. Т.е. шелл-код копируется по какому-то адресу, но не ясно по какому. И, чтобы его узнать, перед копированием подбирается смещение от начала своего стека. Ниже авторы пишут, что это заморочный метод, и что попасть точно на начало удается далеко не сразу, потому начало шелл-кода часто забивают кучей nop-ов. Ты лучше скажи, пример с 37-ой страницы заработал? http://wasm.ru/forum/viewtopic.php?id=39836
milo Вызов system("/bin/bash"); нужен для того, чтобы использовать потом переменную окружения $BUF, которая содержит сформированный шелл-код. Задача подбора адреса сводится к тому, чтобы положить (затерев) в то место стека, откуда берется адрес возврата, значение, которое указывает на код, который должен выполниться.
если ты про опробирование шеллкода, то да, отлично заработал (опять же archlinux): Код (Text): [milo@milo stackoverflow1]$ gcc shellcodes_library.c -o shellcodes [milo@milo stackoverflow1]$ ./shellcodes addr_trans addr_trans.c main main.c shellcodes shellcodes_library.c правда, шеллкоды я брал отсюда: http://www.google.ru/url?sa=t&sourc...5qWkPCKVw&sig2=NYOjwPJF3tIwgk-mkg8DCQ&cad=rjt но там есть тот, который описан на 37ой странице книги.
по поводу своей проблемы: значит надо пыхтеть пока не получу результат? а затем запомнить адрес, который мне предлогался и вписывать его в эксплоит?
milo Как бы так, да. Пробовать разные смещения, если много, убавить, мало -- добавить. С nop'ами в начале легче попасть, тк. интервал шире. Ну а стек выровнен на 4 байта, не так все страшно.
DarkWanderer тогда сейчас под gdb попробую посмотреть с какого адреса начинается этот буфер и нанести точечный удар...
че-то все равно не выходит ничего. нашел под отладчиком адрес, где начинается шеллкод, в буфер вписываю именно этот адрес. если под отладчиком трассировать и сделать jump на этот адрес (0xbffff5ed) то шеллкод успешно выполняется, а если пустить программу в свободное плавание, то она сегфолтит. причем при разборе коредампа: Код (Text): [milo@milo stackoverflow2]$ gdb ./victim core Program terminated with signal 11, Segmentation fault. #0 0xbffff5ed in ?? () (gdb) info registers eax 0x0 0 ecx 0x0 0 edx 0xbf9b1756 -1080354986 ebx 0xb771dff4 -1217273868 esp 0xbf9af410 0xbf9af410 ebp 0xbffff5ed 0xbffff5ed esi 0x0 0 edi 0x0 0 eip 0xbffff5ed 0xbffff5ed eflags 0x210246 [ PF ZF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x 0xbffff5ed 0xbffff5ed: Cannot access memory at address 0xbffff5ed хотя, рискну предположить, что эта область памяти уже освободилась, поэтому нам не дают ее посмотреть... вобщем запускаю все это дело под отладчиком, ставлю брейк на начало шеллкода Код (Text): br *0xbffff5ed и он таки успешно брякается на этом адресе Код (Text): Breakpoint 1, 0xbffff5ed in ?? () (gdb) disas 0xbffff5ed,+10 Dump of assembler code from 0xbffff5ed to 0xbffff5f7: => 0xbffff5ed: nop 0xbffff5ee: jmp 0xbffff60a 0xbffff5f0: pop %esi 0xbffff5f1: xor %eax,%eax 0xbffff5f3: mov %al,0x7(%esi) 0xbffff5f6: lea (%esi),%ebx End of assembler dump. и так далее, вроде гляю по шеллкоду... дохожу до вызова сисколла: Код (Text): (gdb) disas 0xbffff605,+20 Dump of assembler code from 0xbffff605 to 0xbffff619: 0xbffff605: lea 0xc(%esi),%edx => 0xbffff608: int $0x80 0xbffff60a: call 0xbffff5f0 0xbffff60f: das 0xbffff610: bound %ebp,0x6e(%ecx) 0xbffff613: das 0xbffff614: insb (%dx),%es:(%edi) 0xbffff615: jae 0xbffff617 0xbffff617: psadbw %mm7,%mm7 End of assembler dump. (gdb) si process 11273 is executing new program: /bin/ls [Thread debugging using libthread_db enabled] core main nopattack nopattack.c stackoverflow.tar.gz try try.c victim victim.c Program exited normally. все нормально отработало! но под отладчиком... а без него сегфолт... вопрос остается открытым, все также вопрошаю помощи у более опытных...
Код (Text): 0xbffff5ed: Cannot access memory at address 0xbffff5ed Может, не хочет в секции данных выполняться? Ведь и в eip самый первый адрес,-- переход прошел, а дальше нет. Попробуй сменить атрибуты. Тем же ht, например. У жертвы.
DarkWanderer добавил атрибут executable в режиме elf/section headers секции .data и в режиме elf/program headers на всякий случай всем entry добавил тот же атрибут. результат - тот же, все равно сегфолтит. где-то опять что-то упускаю? не тем секциям разрешаю? в этом вопрсе я плаваю...
