Защити свои приложения

Илья Рабинович

Спецвыпуск: Хакер, номер #058, стр. 058-034-1

Как защититься от атаки на переполнение буфера

Многие люди задавали этот вопрос себе и окружающим. Очень возможно, что не раз. Да, защититься от атаки на переполнение буфера очень тяжело. Прежде всего потому, что этот класс атак мало формализован и крайне изощрен. Но, тем не менее, если есть меч, то должен быть и щит!

Щит №1: патчи от производителя

Универсальный метод. Если нет дыры, нет и атаки на нее. Проблема состоит только в трех вещах. Первое: иногда после установки патча некоторые программы начинают работать неправильно. Соответственно, патчи нуждаются в предварительном тестировании, требующем времени. Второе: бывает так, что патчи закрывают дыру лишь частично. Третье: патчи выпускаются с большим (по компьютерным меркам) опозданием. Производителю нужно время на то, чтобы воспроизвести ситуацию у себя в тестовой лаборатории, переписать код, сделать патч, проверить этот патч на совместимость со своими программами и программами сторонних производителей. А пока эта работа идет, пользователь остается беззащитным. А на скольких дырках нет патчей, потому что производитель о них даже не догадывается?

Щит №2: системы обнаружения вторжения (Intrusion Detection System, IDS)

За этим названием скрываются программы, проводящие глубокий сигнатурный анализ сетевых пакетов на известные сигнатуры шелл-кодов. Если при этом анализе будет найдена сигнатура, соответствующая сигнатуре известного шелл-кода, пакет будет заблокирован и атака не достигнет цели. Самая известная подобная система распространяется как Open Source и называется Snort. Эта система очень распространена и популярна, к ней существует гигантское количество сигнатур шелл-кодов, написанных энтузиастами и системными администраторами.

Недостатки подобных систем очевидны. К ним относятся достаточно большое количество ложных срабатываний и неспособность определять те передаваемые по Сети шелл-коды, которые не известны системе. Более того, поскольку часто шелл-коды передаются в зашифрованном виде, стоит сменить алгоритм шифрования даже у всем известного шелл-кода, и системы IDS уже перестают детектировать его. Насколько я знаю, ведутся работы над тем, чтобы IDS могли расшифровывать потенциальные шелл-коды на лету, но мне слабо верится, что в ближайшее время они будут способны на это. Короче говоря, позаимствовав технологию у антивирусов, IDS позаимствовали и их недостатки, прибавив к ним и свои собственные. Конечно, очень красиво с точки зрения маркетинга, что каждый раз, когда IDS ловит пакет c Lovesan, выводится красивое окошечко: "Наша IDS защитила Вас от страшного и опасного вируса Lovesan". Во-первых, такое окошечко, выскакивающее каждые пять минут, уже через двадцать приводит в состояние нервного срыва, а во-вторых, какое реальное значение оно имеет на полностью пропатченной системе, не подверженной данной атаке? А при целенаправленной атаке на переполнение неизвестным для IDS шелл-кодом окошечко так и не выскочит...

Щит №3: файрвол

Работает по принципу "Если отрубить голову, то и насморка не будет". Действительно, если сетевой пакет с шелл-кодом не сможет пройти к уязвимому приложению через отключенный с помощью файрвола порт, то буфер не будет переполнен и атака не состоится. Правда, и приложение при этом перестанет работать правильно. Много ли мы насерфишь в интернете, если файрволом отключен 80-й (HTTP) порт? Думаю, нет. А атак на переполнение буфера под Internet Explorer на моей памяти было много - от знаменитой "уязвимости в картинках" (переполнение буфера при рендеринге JPEG-изображений) до уязвимости в обработчике IFrame-ссылок. Отключаем 80-й порт?