|
Читайте также: |
Код, получаемый управление при срыве стека, запускается от имени и с привилегиями уязвимой программы. Отсюда, наибольший интерес представляют программы, обладающие наивысшими привилегиями (системные сервисы, демоны и т.д.). Это значительно сужает круг поиска и ограничивает количество потенциальных кандидатов в жертвы.
Врезка «замечание» *
Существует некоторые методы, позволяющие предотвратить последствия срыва стека, даже при наличии грубых ошибок реализации. В главах, посвященных безопасности операционных систем UNIX и Windows NT, отмечалось, что все они разрешают выполнение кода в стеке, и поэтому потенциально уязвимы, или же, другими словами, чувствительны к ошибкам программного обеспечения.
На самом же деле это не совсем верно. Существуют экзотические ядра UNIX, запрещающие подобную операцию – при попытке выполнить код, размещенный в стеке, происходит исключение, и выполнение программы прерывается. Но вместе с этим перестают работать многие легальные программы, «на лету» генерирующие код и исполняющие его в стеке [330]. Но запрет на выполнение кода в стеке не затрагивает модификацию переменных, указателей, поэтому принципиальная возможность атак по-прежнему остается. Поэтому, такие ядра используются крайне редко. Тем более, вызов исключение при попытке злоумышленника проникнуть на компьютер, не самая лучшая защита [331].
Некоторые компиляторы (тот же gcc) способны генерировать код, автоматически обнаруживающий выход за границы буфера, но это вызывает снижение производительности в десятки раз и чаще всего оказывается неприемлемо.
Врезка «информация» *
В рамках проекта Synthetix (http://www.cse.ogi.edu/DISC/projects/synthetix) удалось найти несколько простых и надежных решений, затрудняющих атаки, основанные на срыве стека. Например, “StackGuard” – одна из «заплат» к компилятору gcc, дополняет пролог и эпилог каждой из функций, особым кодом, контролирующим целостность адреса возврата. Алгоритм в общих чертах следующий: в стек вместе с адресом возврата заносится, так называемый, “Canary Word”, расположенный до адреса возврата. Искажение адреса возврата обычно сопровождается и искажением Canary Word, что легко проконтролировать. Соль в том, что Canary Word содержит символы “\0”, CR, LF, EOF, которые не могут быть обычным путем введены с клавиатуры. А для усиления защиты добавляется случайная привязка, генерируемая при каждом запуске программы.
Такая мера действительно затрудняет атаки, но не исключает их принципиальную возможность. Существует возможность перезаписи любой области памяти как искажением регистра EBP, используемого для адресации локальные переменных, так и модификацией переменных указателей. Этого StackGuard отследить не в силах. Кроме того, если происходит переполнение буферов, в которых помещается информация, считанная из двоичного файла или принятая по сети, то отсутствует всякое ограничение на передаваемые в строке символы. А узнать значение привязки можно, например, с помощью уязвимости в функции printf (и подобным ей) и т.д.
Существуют различные способы поиска уязвимых программ. Например, с помощью дизассемблирования и тщательного изучения кода, или тривиального ввода строк переменной длины. Как уже отмечалось в главе «Технология срыва стека» недостаточно ограничится вводом максимально длинных строк. Необходимо перебирать все длины от нулевой до максимально возможной.
Манипуляция со строками разной длины – наиболее простой (но не всегда действенный) путь. Если удается подобрать строку, вызывающую исключение, то, следовательно, исследуемая программа содержит уязвимость. Но вовсе не факт, что удастся передать управление на свой код, изменить адрес возврата или каким-то иным способом проникнуть на атакуемую машину. В некоторых случаях ошибки переполнения приводят к возможности блокирования программы, но не позволяют злоумышленнику совершить никакие осмысленные действия.
Поэтому, перед атакующим стоят следующие вопросы: возможно ли искажение адреса возврата таким образом, чтобы он указывал на переданную строку? Если да, то какой байт строки попадает в буфер? Большинство операционных систем при возникновении аварийной ситуации выдают информацию, способную пролить свет на причины аварии. Род и форма выдача информации варьируются от одной операционной системы к другой, но практически всегда приводится содержимое регистров, верхушки стека, инструкции, вызвавшей исключение и номера самого исключения. Этими сведениями и может воспользоваться злоумышленник, чтобы ответить на интересующие его вопросы.
Наименее информативной оказывается Windows 2000, не сообщающая ни содержимое регистров, ни состояние стека. Однако она позволяет загрузить отладчик, с помощью которого легко получить необходимую информацию. Существует так же утилита «Dr. Watson», предназначенная для выяснения причин возникновения аварийных ситуаций. Она великолепно подходит для анализа уязвимых программ.
Ниже будет показано, как можно использовать эту информацию для проникновения на удаленный компьютер. Поскольку, после возникновения исключения ни одна операционная система не передает клиенту сведения о причине аварии (содержимое регистров, состояние стека), то все исследования необходимо проводить на локальной машине. Т.е. злоумышленник должен иметь физический доступ к своей жертве или установить на своем компьютере ту же самую операционную систему и то же самое программное обеспечение.
Если под управлением Windows 2000, в примере buff.demo.exe (на диске, прилагаемом к книге, он находится в файле “/SRC/buff.demo.exe”) ввести строку более чем из двадцати символов ‘Z’ (или любых других символов), произойдет исключение и на окне появится диалоговое окно следующего содержания (смотри рисунок 79):
Рисунок 079 Информация, выдаваемая операционной системой Windows 2000 при возникновении исключительной ситуации
“Инструкция по адресу 0x5a5a5a5a обратилась к памяти по адресу 0x5a5a5a5a. Память не может быть read”. Код символа ‘Z’ равен 0x5A, следовательно, искажение адреса возврата позволило передать управление по адресу ‘ZZZZ’ или 0x5a5a5a5a в шестнадцатеричной форме. Но какие именно байты строки затирают адрес возврата?
Это можно узнать вводом строки с различными символами, например, “ZZZZZZZZZZZZZZZ1234567” (поскольку исключение «выплевывается» только при вводе строки длинной в шестнадцать и более символов, первые пятнадцать символов оказываются незначащими, и их значение роли не играет).
Вновь возникнет исключительная ситуация и на экране появится диалог следующего содержания (смотри рисунок 081):
Рисунок 081
“Инструкция по адресу 0x35343332 обратилась к памяти по адресу 0x35343332. Память не может быть read”. Код символа ‘2’ – 0x32, ‘3’ – 0x33, ‘4’ – 0x34 и ‘5’ – 0x35. Следовательно, в сохраненный адрес возврата попадают шестнадцатый, семнадцатый, восемнадцатый и девятнадцатый символ вводимой строки (без учета завершающего нуля).
Остается выяснить, по какому адресу расположен буфер, содержащий строку. Однако выяснить его только лишь на основе сообщаемой Windows 2000 информации невозможно. Необходимо запустить отладчик, кликнув по кнопке «отмена» (эта кнопка появляется только в том случае, если в системе установлен отладчик, например, среда Microsoft Visual C++, необходимо отметить – SoftIce в штатной инсталляции не предоставляет такой возможности):
После всплытия окна отладчика наибольший интерес представит значение регистра указателя верхушки стека ESP. Само же содержимое стека выше регистра ESP (где и располагается веденная строка) к этому моменту чаще всего оказывается уничтожено.
На рисунке 082 показано содержимое регистров и состояния стека. Легко видеть, что в стеке на месте введенной строки находится мусор. Это происходит потому, что при возникновении исключения в стек заносятся некоторые служебные данные, затирая все на своем пути.
Рисунок 082
Основываясь на значении регистра ESP (равного в данном случае 0x12FF80) легко вычислить адрес первого байта буфера, содержащего строку. Он равен 0x0012FF80 – 0x14[332] = 0x0011FF6C.
Если попробовать ввести строку наподобие: “\xCCZZZZZZZZZZZZZZ\x80\xFF\x12”, (код 0xCC это опкод команды INT 0x3 – вызывающий отладочное исключение 0х3 – только так можно гарантировать возникновение исключения в первом же байте, получившим управление), то результат будет следующим (смотри рисунок 083):
Рисунок 083
“Исключение Unknown software exemption (0x800000003) в приложении по адресу 0x0012FF6C”. Адрес 0x9912FF6C доказывает, что адрес возврата действительно подобран правильно и первый байт переданной строки получает управление.
Таким образом, вся информация, необходимая для вторжения на чужую машину получена, и злоумышленник может приступать к программной реализации атакующего кода, примеры которого были приведены в главе «Технология срыва стека» и дополнении «Использование срыва стека для запуска командного интерпретатора под Windows NT».
Под управлением Windows 9x ту же операцию выполнить намного проще, поскольку она позволяет узнать содержимое регистров и состояние стека нажатием на клавишу «сведения». На экране отобразится диалоговое окно наподобие изображенного на рисунке 080.
Рисунок 080
Наибольший интерес представляет значение регистра ESP, значение которого позволяет вычислить местоположение введенной строки в стеке. Значение регистра EBP, равного 0x5A5A5A5A говорит о том, что компилятор сгенерировал код, адресующий локальные переменные с помощью регистра EBP. Вполне возможно, что модификацией сохраненного значения EBP злоумышленнику удастся проникнуть на машину или, по крайне мере, «завесить» ее.
В штатную поставку Windows 9x, Windows NT 4.x, Windows 2000 входит утилита «Dr. Watson», предназначенная для выявления причин ошибок. При возникновении аварийной ситуации она сохраняет текущее состояние некорректно работающего приложения в файл протокола, в который (в зависимости от настоек) могут входить: содержимое регистров и состояние стека, истории трассировки и т.д.
Один из примеров протокола приведен ниже[333]. Он получен после возникновения исключения в результате переполнения буфера программы buff.demo.exe:
· Состояние системы на 15.09.00 10:31:30.
·
· *----> Итог/Описание <----*
·
· Приложение или одна из ее DLL могла переполнить
· внутренний временный буфер
·
· Имя модуля: <нет данных>
·
· Название приложения: Buff.demo.exe
·
· --------------------
·
· *----> Сведения <----*
·
· Command line: F:\TPNA\SRC\BUFFDE~1.EXE
·
· Trap 0e 0000 - Недопустимая страница
· eax=00000000 ebx=00530000 ecx=00406050 edx=0063fdd8 esi=817d3fd4 edi=00000000
· eip= 5a5a5a5a esp= 0063fdf8 ebp=5a5a5a5a -- -- -- nv up EI pl ZR na PE nc
· cs=015f ss=0167 ds=0167 es=0167 fs=41a7 gs=0000
· >015f:5a5a5a5a page not present
· sel type base lim/bot
· –––---- ---- -------- --------
· cs 015f r-x- 00000000 ffffffff
· ss 0167 rw-e 00000000 0000ffff
· ds 0167 rw-e 00000000 0000ffff
· es 0167 rw-e 00000000 0000ffff
· fs 41a7 rw-- 817d23fc 00000037
· gs 0000 ----
·
· stack base: 00540000
· TIB limits: 0063e000 - 00640000
·
· -- exception record --
·
· Exception Code: c0000005 (нарушение доступа)
· Exception Address: 5a5a5a5a
· Exception Info: 00000000
· 5a5a5a5a
·
· >015f:5a5a5a5a page not present
·
·
· -- stack summary --
·
· 0167:5a5a5a5a 015f:5a5a5a5a 015f:5a5a5a5a
·
· -- stack trace --
·
· 0167:5a5a5a5a 015f:5a5a5a5a 015f:5a5a5a5a
·
· -- stack dump --
·
· 0063fdf8 00005a5a
· 0063fdfc 00401262 = BUFF.DEMO.EXE:.text+0x262
·
· --------------------
· 015f:00401231 00a330694000 add byte ptr [ebx+00406930],ah
· 015f:00401237 e83f0e0000 call 0040207b = BUFF.DEMO.EXE:.text+0x107b
· 015f:0040123c e8810d0000 call 00401fc2 = BUFF.DEMO.EXE:.text+0xfc2
· 015f:00401241 e8f60a0000 call 00401d3c = BUFF.DEMO.EXE:.text+0xd3c
· 015f:00401246 a170694000 mov eax,dword ptr [00406970]
· 015f:0040124b a374694000 mov dword ptr [00406974],eax
· 015f:00401250 50 push eax
· 015f:00401251 ff3568694000 push dword ptr [00406968]
· 015f:00401257 ff3564694000 push dword ptr [00406964]
· 015f:0040125d e80afeffff call 0040106c = BUFF.DEMO.EXE:.text+0x6c
· BUFF.DEMO.EXE:.text+0x262:
· *015f:00401262 83c40c add esp,+0c
· 015f:00401265 8945e4 mov dword ptr [ebp-1c],eax
· 015f:00401268 50 push eax
· 015f:00401269 e8fb0a0000 call 00401d69 = BUFF.DEMO.EXE:.text+0xd69
· 015f:0040126e 8b45ec mov eax,dword ptr [ebp-14]
· 015f:00401271 8b08 mov ecx,dword ptr [eax]
· 015f:00401273 8b09 mov ecx,dword ptr [ecx]
· 015f:00401275 894de0 mov dword ptr [ebp-20],ecx
· 015f:00401278 50 push eax
· 015f:00401279 51 push ecx
· 015f:0040127a e8bf0b0000 call 00401e3e = BUFF.DEMO.EXE:.text+0xe3e
·
· --------------------
·
·
· 0063fe00 00000001
· 0063fe04 00760b70 -> 78 0b 76 00 00 00 00 00 46 3a 5c 54 50 4e 41 5c x.v.....F:\TPNA\
· 0063fe08 00760b20 -> 00 0b 76 00 e0 0a 76 00 c0 0a 76 00 a0 0a 76 00..v...v...v...v.
· 0063fe0c 00000000
· 0063fe10 817d3fd4 -> 06 00 05 00 50 e9 52 c1 00 00 00 00 00 00 00 00....P.R.........
· 0063fe14 00530000
· 0063fe18 c0000005
· 0063fe1c 0063ff68 -> ff ff ff ff 14 fe fb bf 38 91 f7 bf 00 00 00 00........8.......
· 0063fe20 0063fe0c -> 00 00 00 00 d4 3f 7d 81 00 00 53 00 05 00 00 c0.....?}...S.....
· 0063fe24 0063fc28 -> 00 fd 63 00 1c fd 63 00 54 fc 63 00 4d 68 f7 bf..c...c.T.c.Mh..
· 0063fe28 0063ff68 -> ff ff ff ff 14 fe fb bf 38 91 f7 bf 00 00 00 00........8.......
· 0063fe2c 004026dc = BUFF.DEMO.EXE:.text+0x16dc
· -> 55 8b ec 83 ec 08 53 56 57 55 fc 8b 5d 0c 8b 45 U.....SVWU..]..E
· 0063fe30 004050a8 = BUFF.DEMO.EXE:.rdata+0xa8
· -> ff ff ff ff 6e 12 40 00 82 12 40 00 06 00 00 06....n.@...@.....
· 0063fe34 00000000
· 0063fe38 0063ff78 -> f4 ff 63 00 e9 b3 f8 bf f4 23 7d 81 d4 3f 7d 81..c......#}..?}.
· 0063fe3c bff8b537 = KERNEL32!ApplicationStartup
·
· --------------------
·
Этот протокол полезен тем, что позволяет установить: в какой процедуре произошло переполнение буфера. В листинге знаком звездочки отмечена инструкция, следующая за командой, вызвавшей исключение:
· 015f:0040125d e80afeffff call 0040106c = BUFF.DEMO.EXE:.text+0x6c
· BUFF.DEMO.EXE:.text+0x262:
· *015f:00401262 83c40c add esp,+0c
С помощью IDA легко установить, что процедура, располагающая по адресу 0x40106C, представляет собой main():
·.text:0040106C main proc near; CODE XREF: start+AFp
·.text:0040106C push ebp
·.text:0040106D mov ebp, esp
Но переполнение буфера произошло в процедуре auth, ссылок на адрес которой (0х401000) в протоколе, выданном Доктором Ватсоном вообще нет! Это происходит потому что, адрес возврата из процедуры auth был затерт введенной строкой и Доктор Ватсон не смог определить откуда произошел вызов. Исключение вызвала не сама функция main, а одна из вызываемых ею процедур. Установить же истинного «виновника» исключения теперь практически невозможно.
Единственной зацепкой, за которую можно ухватиться оказываются параметры переданные функции (если они не были затерты[334]). По роду и значению параметров можно хотя бы приблизительно определить какая функция была вызвана. По крайней мере, это позволит сузить круг поиска.
Но далеко не во всех случаях ошибки переполнения удается обнаружить перебором строк разной длины. Наглядной демонстрацией этого утверждения служит следующая программа (на диске, прилагаемом к книге, она находится в файле “/SRC/buff.src.c”):
· #include <stdio.h>
· #include <string.h>
· #include <windows.h>
·
· int file(char *buff)
· {
· char *p;
· int a=0;
· char proto[10];
· p=strchr(&buff[0],':');
· if (p)
· {
· for (;a!=(p-&buff[0]);a++)
· proto[a]=buff[a];
·
· proto[a]=0;
·
· if (strcmp(&proto[0],"file"))
· return 0;
· else
· WinExec(p+3,SW_SHOW);
·
· }
· else
· WinExec(&buff[0],SW_SHOW);
· return 1;
·
· }
·
·
· main(int argc,char **argv)
· {
· if (argc>1) file(&argv[1][0]);
· }
Программа запускает файл, имя которого указано в командной строке. Попытка вызвать переполнение вводом строк различной длины, скорее всего, ни к чему не приведет. Но даже беглый анализ исходного кода позволит обнаружить ошибку, допущенную разработчиком.
Если в имени файла присутствует символ “:”, то программа полагает, что имя записано в формате “протокол://путь к файлу/имя файла”, и пытается выяснить какой именно протокол был указан. При этом она копирует название протокола в буфер фиксированного размера, полагая, что при нормальном ходе вещей, его хватит для вмещения имени любого протокола. Но если ввести строку наподобие “ZZZZZZZZZZZZZZZZZZZZZZ: ”, то произойдет переполнение буфера со всеми вытекающими отсюда последствиями (см. рисунок 084).
Рисунок 084
Приведенный пример относится к самым простым. Но существуют более коварные ошибки, проявляющиеся лишь при стечении определенных обстоятельств и обнаружить их можно только случайно или тщательным изучением исходных кодов (а в отсутствии исходных кодов – дизассемблированием или отладкой).
В первую очередь необходимо отобразить внимание на буфера фиксированного размера, расположенные в стеке. Блоки памяти, выделяемые вызовом alloc, находятся в куче (heap) и их переполнение (даже если и имеет место) не приводит к модификации адреса возврата, сохраненного в стеке.
Но четкую инструкцию по поиску ошибок дать невозможно. Существует множество разнообразных техник и подходов к решению этой проблемы, но никакой алгоритм не в в состоянии обнаруживать все уязвимости, поскольку всегда возможно возникновение принципиально новой идеи, наподобие приема, основанного на вводе спецификаторов в строке, передаваемой функции printf[335]. Автоматизированные средства поиска научаться обнаружить такие ошибки не раньше, чем обзаведутся искусственным интеллектом.
В сложных программах огрехи были, если и будут всегда. Тщательное тестирование миллионов строк кода современных приложений экономически не выгодно и не практикуется ни одной компанией. С другой стороны, анализ чужого кода (а особенно в отсутствии исходных текстов) выполнить в одиночку затруднительно. Большинство ошибок обнаруживаются случайно, а не в результате целенаправленного поиска. Но существует огромное количество злоумышленников, располагающих неограниченным (ну, практически неограниченным) временем для экспериментов, поэтому, новые ошибки обнаруживаются чуть ли не ежедневно (и часто по несколько в день).
Дата добавления: 2015-11-14; просмотров: 39 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Дополнение. Шифровка кода | | | Как устроен генератор паролей? |