Мы полагаем, что эта книга важна, поскольку в работе над ней приняли участие трое наиболее авторитетных на сегодняшний день специалистовпрактиков в сфере безопасности, а также потому, что она охватывает все распространенные языки и платформы для развертывания программ. Надеемся, что вы найдете здесь немало полезной информации.
Майкл Ховард, Дэвид Лебланк, Джон Виега, июль 2005 г.
Грех 1.Переполнение буфера
В чем состоит грех
Уже давно ясно, что переполнение буфераэто проблема всех низкоуровневых языков программирования. Возникает она потому, что в целях эффективности данные и информация о потоке выполнения программы перемешаны, а в низкоуровневом языке разрешен прямой доступ к памяти. С и С++ больше других языков страдают от переполнений буфера.
Строго говоря, переполнение возникает, когда программа пытается писать в память, не принадлежащую выделенному буферу, но есть и ряд других ошибок, приводящих к тому же эффекту. Одна из наиболее интересных связана с форматной строкой, мы рассмотрим ее в описании греха 2. Еще одно проявление той же проблемы встречается, когда противнику разрешено писать в произвольную область памяти за пределами некоторого массива. И хотя формально это не есть классическое переполнение буфера, мы рассмотрим здесь и этот случай.
Результатом переполнения буфера может стать что угодноот краха программы до получения противником полного контроля над приложением, а если приложение запущено от имени пользователя с высоким уровнем доступа (root, Administrator или System), то и над всей операционной системой и другими пользователями. Если рассматриваемое приложениеэто сетевая служба, то ошибка может привести к распространению червя. Первый получивший широкую известность Интернетчервь эксплуатировал ошибку в сервере finger, он так и назывался«fingerчервь Роберта Т. Морриса» (или просто «червь Морриса»). Казалось бы, что после того как в 1988 году Интернет был поставлен на колени, мы уже должны научиться избегать переполнения буфера, но и сейчас нередко появляются сообщения о такого рода ошибках в самых разных программах.
Быть может, ктото думает, что такие ошибки свойственны лишь небрежным и беззаботным программистам. Однако на самом деле эта проблема сложна, решения не всегда тривиальны, и всякий, кто достаточно часто программировал на С или С++, почти наверняка хоть раз да допускал нечто подобное. Автор этой главы, который учит других разработчиков, как писать безопасный код, сам однажды передал заказчику программу, в которой было переполнение на одну позицию (offbyone overflow). Даже самые лучшие, самые внимательные программисты допускают ошибки, но при этом они знают, насколько важно тщательно тестировать программу, чтобы эти ошибки не остались незамеченными.
Подверженные греху языки
Чаще всего переполнение буфера встречается в программах, написанных на С, недалеко от него отстает и С++. Совсем просто переполнить буфер в ассемблерной программе, поскольку тут нет вообще никаких предохранительных механизмов. По существу, С++ так же небезопасен, как и С, поскольку основан на этом языке. Но использование стандартной библиотеки шаблонов STL позволяет свести риск некорректной работы со строками к минимуму, а более строгий компилятор С++ помогает программисту избегать некоторых ошибок. Даже если ваша программа составлена на чистом С, мы все же рекомендуем использовать компилятор С++, чтобы выловить как можно больше ошибок.
В языках более высокого уровня, появившихся позже, программист уже не имеет прямого доступа к памяти, хотя за это и приходится расплачиваться производительностью. В такие языки, как Java, С# и Visual Basic, уже встроены строковый тип, массивы с контролем выхода за границы и запрет на прямой доступ к памяти (в стандартном режиме). Ктото может сказать, что в таких языках переполнение буфера невозможно, но правильнее было бы считать, что оно лишь гораздо менее вероятно. Ведь в большинстве своем эти языки реализованы на С или С++, а ошибка в реализации может стать причиной переполнения буфера. Еще один потенциальный источник проблемы заключается в том, что на какойто стадии все эти высокоуровневые языки должны обращаться к операционной системе, а уж онато почти наверняка написана на С или С++. Язык С# позволяет обойти стандартные механизмы .NET, объявив небезопасный участок с помощью ключевого слова unsafe. Да, это упрощает взаимодействие с операционной системой и библиотеками, написанными на C/C++, но одновременно открывает возможность допустить обычные для C/C++ ошибки. Даже если вы программируете преимущественно на языках высокого уровня, не отказывайтесь от тщательного контроля данных, передаваемых внешним библиотекам, если не хотите пасть жертвой содержащихся в них ошибок.
Мы не станем приводить исчерпывающий список языков, подверженных ошибкам изза переполнения буфера, скажем лишь, что к их числу относится большинство старых языков.
Как происходит грехопадение
Классическое проявление переполнения буфераэто затирание стека. В откомпилированной программе стек используется для хранения управляющей информации (например, аргументов). Здесь находится также адрес возврата из функции и, поскольку число регистров в процессорах семейства х86 невелико, сюда же перед входом в функцию помещаются регистры для временного хранения. Увы, в стеке же выделяется память для локальных переменных. Иногда их неправильно называют статически распределенными в противоположность динамической памяти, выделенной из кучи. Когда ктото говорит о переполнении статического буфера, он чаще всего имеет в виду переполнение буфера в стеке. Суть проблемы в том, что если приложение пытается писать за границей массива, распределенного в стеке, то противник получает возможность изменить управляющую информацию. А это уже половина успеха, ведь цель противникамодифицировать управляющие данные по своему усмотрению.
Возникает вопрос: почему мы продолжаем пользоваться столь очевидно опасной системой? Избежать проблемы, по крайней мере частично, можно было бы, перейдя на 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;
}
Откомпилируем эту программу и посмотрим, что произойдет. Для демонстрации автор собрал приложение, включив отладочные символы и отключив контроль стека. Хороший компилятор предпочел бы встроить такую короткую функцию, как DontDoThis, особенно если она вызывается только один раз, поэтому оптимизация также была отключена. Вот как выглядит стек непосредственно перед вызовом strcpy:
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()
Напомним, что стек растет сверху вниз (от старших адресов к младшим). Этот пример выполнялся на процессоре Intel со схемой адресации «littleendian». Это означает, что младший байт хранится в памяти первым, так что адрес возврата «3f104000» на самом деле означает 0x0040103f.
А теперь посмотрим, что происходит, когда буфер buf переполняется. Сразу вслед за buf находится сохраненное значение регистра EBP (Extended Base Pointerрасширенный указатель на базу). ЕВР содержит указатель кадра стека; при ошибке на одну позицию его значение будет затерто. Если противник сможет получить контроль над областью памяти, начинающейся с адреса 0x0012fe00 (последний байт вследствие ошибки обнулен), то программа перейдет по этому адресу и выполнит помещенный туда противником код.
Если не ограничиваться переполнением на один байт, то следующим будет затерт адрес возврата. Коль скоро противник сумеет получить контроль над этим значением и записать в буфер, адрес которого известен, достаточное число байтов ассемблерного кода, то мы будем иметь классический пример переполнения буфера, допускающего написание эксплойта. Отметим, что ассемблерный код (его обычно называют shellкодом, потому что чаще всего задача эксплойтаполучить доступ к оболочке (shell)) необязательно размещать именно в перезаписываемом буфере. Это типичный случай, но, вообще говоря, код можно внедрить в любое место вашей программы. Не обольщайтесь, полагая, что переполнению подвержен только очень небольшой участок.
После того как адрес возврата переписан, в распоряжении противника оказываются аргументы атакуемой функции. Если функция перед возвратом какимто образом модифицирует переданные ей аргументы, то открываются новые соблазнительные возможности. Это следует иметь в виду, оценивая эффективность таких средств борьбы с переполнением стека, как программа Stackguard Криспина Коуэена (Crispin Cowan), программа ProPolice, распространяемая IBM, и флаг /GS в компиляторе Microsoft.
Как видите, мы предоставили противнику как минимум три возможности получить контроль над нашим приложением, а это ведь была очень простая функция. Если в стеке объявлен объект класса С++ с виртуальными функциями, то станет доступна таблица указателей на виртуальные функции; такая ошибка тоже легко эксплуатируется. Если одним из аргументов функции является указатель на функцию, что часто бывает в оконных системах (например, в X Window System или Microsoft Windows), то перезапись этого указателя перед использованиемочевидный способ получить контроль над приложением.
Есть множество хитроумных способов перехватить управление программой, гораздо больше, чем способен измыслить наш слабый ум. Существует несоответствие между возможностями и ресурами, доступными разработчику и хакеру. В своей работе вы ограничены сроками, тогда как противник может тратить все свое свободное время на то, чтобы придумать, как заставить вашу программу делать то, что нужно ему. Ваша программа может защищать ресурс, достаточно ценный, чтобы потратить на ее взлом несколько месяцев. Хакер тратит массу времени на то, чтобы быть в курсе последних достижений в области взлома. К его услугамтакие ресурсы, как www.metasploit.com, позволяющие в несколько «кликов» создать shellкод, который будет делать что угодно и при этом включать только символы из ограниченного набора.
Если вы попытаетесь выяснить, можно ли создать эксплойт для какойто программы, то, скорее всего, полученный ответ будет неполным. В большинстве случае можно лишь доказать, что программа либо уязвима, либо вы недостаточно хитроумны (или потратили на поиск решения недостаточно времени), чтобы написать для нее эксплойт. Очень редко можно с уверенностью утверждать, что для некоторого переполнения эксплойт невозможен.
Мораль, стало быть, в том, что самое правильноеисправить ошибки! Сколько раз случалось, что модификации с целью «повысить качество кода» заодно приводили и к исправлению ошибок, связанных с безопасностью. Автор както битых три часа убеждал команду разработчиков исправить некую ошибку. В переписке приняло участие восемь человек, и мы потратили 20 человекочасов (половина рабочей недели одного программиста), споря, нужно ли исправлять ошибку, поскольку разработчики жаждали получить доказательства того, что для нее можно написать эксплойт. Когда эксперты по безопасности доказали, что проблема действительно есть, для исправления потребовался час работы программиста и еще четыре часа на Тестирование. Сколько же времени ушло впустую!
Заниматься анализом надо непосредственно перед поставкой программы. На завершающих стадиях разработки хорошо бы иметь обоснованное предположение о том, достаточно ли велика опасность написания эксплойта для ошибки, чтобы оправдать риск, связанный с переделками и, как следствие, нестабильностью продукта.
Распространено заблуждение, будто переполнение буфера в куче не так опасно, как буфера в стеке. Это совершенно неправильно. Большинство реализаций кучи страдают тем же фундаментальным пороком, что и стек, пользовательские и управляющие данные хранятся вместе. Часто можно заставить менеджер кучи поместить четыре указанных противником байта по выбранному им же адресу. Детали атаки на кучу довольно сложны. Недавно Matthew «shok» Conover и Oded Horovitz подготовили очень ясную презентацию на эту тему под названием «Reliable Windows Heap Exploits» («Надежный эксплойт переполнения кучи в Windows»), которую можно найти на странице http://cansecwest.com/csw04/csw04Oded+Connover.ppt. Даже если сам менеджер кучи не поддается взломщику, в соседних участках памяти могут находиться указатели на функции или на переменные, в которые записывается информация. Когдато эксплуатация переполнений кучи считалась экзотическим и трудным делом, теперь же это одна из самых распространенных атакуемых ошибок.
Греховность C/C++
В программах на языках C/C++ есть масса способов переполнить буфер. Вот строки, породившие fingerчервя Морриса:
char buf[20] ;
gets (buf) ;
Не существует никакого способа вызвать gets для чтения из стандартного ввода без риска переполнить буфер. Используйте вместо этого fgets. Наверное, второй по популярности способ вызвать переполнениеэто воспользоваться функцией strcpy (см. предыдущий пример). А вот как еще можно напроситься на неприятности:
char buf[20];
char prefix[] = "http://";
strcpy(buf, prefix);
strncat(buf, path, sizeof(buf));
Что здесь не так? Проблема в неудачном интерфейсе функции strncat. Ей нужно указать, сколько символов свободно в буфере, а не общую длину буфера. Вот еще один распространенный код, приводящий к переполнению:
char buf[MAX_PATH];
sprintf(buf, "%s%d\n", path, errno);
Если не считать нескольких граничных случаев, функцию sprintf почти невозможно использовать безопасно. Для Microsoft Windows было выпущено извещение о критической ошибке, связанной с применением sprintf для отладочного протоколирования. Подробности см. в бюллетене MS04011 (точная ссылка приведена в разделе «Другие ресурсы»).
А вот еще пример:
char buf [ 32] ;
strncpy(buf, data, strlen(data));
Что неверно? В последнем аргументе передана длина входного буфера, а не размер целевого буфера!
Еще один способ столкнуться с проблемойпо ошибке считать байты вместо символов. Если вы работаете с кодировкой ASCII, то между ними нет разницы, но в кодировке Unicode один символ представляется двумя байтами. Вот пример:
_snwprintf(wbuf, sizeof(wbuf), «%s\n», input);
Следующее переполнение несколько интереснее:
bool CopyStructs(InputFile* pInFile, unsigned long count)
{
unsigned long i;
m_pStructs = new Structs[count];
for(i = 0; i < count; i++)
{
if(!ReadFromFile(pInFile, &(m_pStructs[i])))
break;
}
}
Как здесь может возникнуть ошибка? Оператор new[] в языке С++ делает примерно то же, что такой код:
ptr = malloc(sizeof(type) * count);