Дэвид Лебланк , Майкл Ховард , Джон Виега - 19 смертных грехов, угрожающих безопасности программ

Возникает вопрос: почему мы продолжаем пользоваться столь очевидно опасной системой? Избежать проблемы, по крайней мере частично, можно было бы, перейдя на 64–разрядный процессор Intel Itanium, где адрес возврата хранится в регистре. Но тогда пришлось бы смириться с утратой обратной совместимости, хотя на момент работы над этой книгой представляется, что процессор х64 в конце концов станет популярным.

Можно также спросить, почему мы не переходим на языки, осуществляющие строгий контроль массивов и запрещающие прямую работу с памятью. Дело в том, что для многих приложений производительность высокоуровневых языков недостаточно высока. Возможен компромисс: писать интерфейсные части программ, с которыми взаимодействуют пользователи, на языке высокого уровня, а основную часть кода – на низкоуровневом языке. Другое решение–в полной мере задействовать возможности С++ и пользоваться написанными для него библиотеками для работы со строками и контейнерными классами. Например, в Web–сервере Internet Information Server (IIS) 6.0 обработка всех входных данных переписана с использованием строковых классов; один отважный разработчик даже заявил, что даст отрезать себе мизинец, если в его коде отыщется хотя бы одно переполнение буфера. Пока что мизинец остался при нем, и за два года после выхода этого сервера не было опубликовано ни одного сообщения о проблемах с его безопасностью. Поскольку современные компиляторы умеют работать с шаблонными классами, на С++ теперь можно создавать очень эффективный код.

Но довольно теории, рассмотрим пример.

...

tinclude <stdio.h>

void DontDoIhis (char* input)

{

char buf[16];

strcpy(buf, input);

printf("%s\n» , buf);

}

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

{

// мы не проверяем аргументы

// а чего еще ожидать от программы, в которой используется

// функция strcpy?

DontDoThis(argv[l]);

return 0;

}

...

0x0012FEC0  с8  fe 12 00 .. <– адрес аргумента buf

0x0012FEC4  с4 18 32 00 .2. <– адрес аргумента input

0x0012FEC8  d0 fe 12 00 .. <– начало буфера buf

0x0012FECC  04 80 40 00  .<<Unicode: 80>>@.

0x0012FED0  el 02 3f 4f     .?0

0x0012FED4  66 00 00 00    f… <– конец buf

0x0012FED8  e4 fe 12 00     .. <– содержимое регистра EBP

0x0012FEDC  3f 10 40 00  ?.@. <– адрес возврата

0x0012FEE0  c4 18 32 00    .2. <– адрес аргумента DontDoThis

0x0012FEE4  cO ff 12 00     ..

0x0012FEE8  10 13 40 00  ..@. <– адрес, куда вернется main()

А теперь посмотрим, что происходит, когда буфер buf переполняется. Сразу вслед за buf находится сохраненное значение регистра EBP (Extended Base Pointer – расширенный указатель на базу). ЕВР содержит указатель кадра стека; при ошибке на одну позицию его значение будет затерто. Если противник сможет получить контроль над областью памяти, начинающейся с адреса 0x0012fe00 (последний байт вследствие ошибки обнулен), то программа перейдет по этому адресу и выполнит помещенный туда противником код.

Если не ограничиваться переполнением на один байт, то следующим будет затерт адрес возврата. Коль скоро противник сумеет получить контроль над этим значением и записать в буфер, адрес которого известен, достаточное число байтов ассемблерного кода, то мы будем иметь классический пример переполнения буфера, допускающего написание эксплойта. Отметим, что ассемблерный код (его обычно называют shell–кодом, потому что чаще всего задача эксплойта – получить доступ к оболочке (shell)) необязательно размещать именно в перезаписываемом буфере. Это типичный случай, но, вообще говоря, код можно внедрить в любое место вашей программы. Не обольщайтесь, полагая, что переполнению подвержен только очень небольшой участок.