25 января 2003 года червь SQL Slammer (w2.SQLSlammer.worm), он же Sapphire (согласно F-Secure), он же w32.SQLexp.worm (согласно Symantec), он же Helkern (согласно Касперскому), эффективно использовал известные уязвимости в серверах Microsoft SQL 2000, вызвав жуткие заторы в сетях по всему миру. В данной статье предлагается приложение концепций популяционной биологии к программированию. Идея заключается в диверсификации одной и той же функциональности среди популяции исполняемых модулей во избежание поражения вирусом или червем, аналогичным SQL Slammer.

В биологии хорошо известен тот факт, что виды с разнообразными популяциями более устойчивы к вымиранию под давлением естественного отбора, чем виды с "клонированной" популяцией. Я считаю это одной из важных причин необходимости поддержания биологического разнообразия.

На этих выходных SQL Slammer использовал не только уязвимости в Microsoft SQL 2000, но и уязвимости в стандартных методах распространения программных пакетов. Обычный программный пакет содержит одни и те же документы, одни и те же исполняемые файлы. Другими словами, пакет просто копируется, или "клонируется" без изменений. Я считаю, что произошедшее дает нам урок важности разнообразия и в компьютерном мире.

После внимательного изучения кода SQL Slammer становится понятно, что этот червь был весьма избирателен. Будь популяция SQL 2000 более разнообразной, удар SQL Slammer оказался бы не столь чувствителен.

Итак, я предлагаю концепцию компоновки на этапе установки в целях диверсификации функциональности приложения среди популяции исполняемых файлов. Другими словами, различные исполняемые модули имеют одну и ту же функциональность.

Рис. 1. Компоновка объектных файлов в исполняемый модуль на этапе установки

Идея компоновки во время установки заключается в том, чтобы собирать исполняемый модуль случайным образом (включая таблицу импорта, атакованную SQL Slammer'ом). С точки зрения функциональности, исполняемые файлы #1 и #2 (Рис. 2) одинаковы, хотя их образы отличаются. Следовательно, программа, подобно SQL Slammer'у, нацеленная на определенный исполняемый модуль, потеряет свою эффективность в случае другого исполняемого модуля из-за измененного распределения адресов (к сожалению, при этом она может испортить приложение).

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

Продолжая данную идею, операционная система могла бы осуществлять динамическую компоновку библиотек или исполняемых файлов случайным образом для дальнейшего разнообразия.

Насколько данная концепция практична, покажет время.

Замечания

После написания этого текста я обратился к нескольким людям для его оценки. Приведенные далее комментарии позволяют подробнее раскрыть мою идею.

• Компоновка на этапе установки не остановит внедрение кода до тех пор, пока у вас не будет неисполняемого стека и кучи, поскольку любой внедряемый код позволит обойти рандомизацию.

  Ответ автора:

  Моя идея заключается не в том, чтобы препятствовать внедрению кода (будем надеяться, что весь написанный код свободен от ошибок :-) ). Идея в том, чтобы внедрение кода имело разные последствия на разных машинах. Буквально только что я говорил с моим приятелем, специализирующемся в вирусологии, и поделился этой идеей. Пусть, к примеру, у нас есть пять машин с установленным SQL server 2000 SP2, все они подвержены SQL slammer. Будучи зараженными, все пять машин станут источником заражения других машин либо замедления сети. С популяционистской концепцией, все пять машин по-прежнему подвержены переполнению буфера либо внедрению кода. Однако, предположим, что благодаря рандомизации адресов (особенно в секции IMPORTS), две из пяти машин станут дальнейшим источником инфекции, а три остальные "упадут" разными способами и не превратятся в источник заражения (что в итоге замедлит распространение инфекции и окажет меньшее воздействие на загрузку сети).

  Таким образом, целью популяционистской концепции является не создание препятствий внедрению кода или созданию ложного чувства безопасности. Ее цель - создание вариаций в целях обеспечения разного поведения популяции под атакой. К примеру, люди подвержены ВИЧ-инфекции и при заражении умирают от СПИДа. Однако, пациенты, зараженные ВИЧ-инфекцией реагируют по-разному. Некоторые сопротивляются в течение длительного времени, некоторые быстро умирают. К сожалению, в случае единственного клонированного исполняемого модуля, все бы вели себя точно как SQL server 2000 под атакой Slammer'а. Надеюсь, эта аналогия вам понятна.

• Эта идея уже обсуждалась много раз. Эта и подобные техники, следующие принципу "безопасность за счет неизвестности" ("security through obscurity") обычно отвергаются. Данный подход не решает саму проблему, а напускает туману в надежде на то, что оппоненты побоятся приложить достаточно усилий для его преодоления. История показала, что это приводит к опасному ложному чувству безопасности. Да, в краткосрочной перспективе черви действительно могут замедлиться, если адресация памяти будет рандомизирована. Но ложное чувство безопасности может оказаться весьма пагубным в долгосрочной перспективе.

  Ответ автора:

  Большое спасибо за трату своего время на ответ. Я понимаю, что вы имеете в виду. Моя идея заключается не в том, чтобы помешать определенному червю. Она направлена на предотвращение того, чтобы заражение стало цепной реакцией (в физических терминах), или каскадной реакцией (в биологических терминах), или снежной лавиной, как это произошло с SQL Slammer'ом в минувшие выходные. В случае различия в формате одних и тех же исполняемых файлов, такой простой вирус как SQL Slammer не смог бы нанести такой серьезный удар. Все SQl-серверы, атакованные им, упали бы тем или иным образом. Однако, не все из них стали бы источником распространения инфекции. В этом заключается цель диверсификации: в популяции могут найтись особи, которые переживут инфекцию или атаку, направленную на определенную породу. Если жестко прописанные адреса внутри вируса или червя совпадают с теми, что находятся внутри исполняемого модуля, он превратится в машину для убийства. Если они указывают в никуда, сервер падает, перезагружается и функционирует нормально до следующей атаки, затем падает еще раз и т.п. Однако, он не присоединяется к борьбе за замедление трафика.

  Конечно, вы можете возразить, что вирус может обладать чуть большим интеллектом, или, к примеру, действовать методом перебора. Это уже совсем другая история. Однако, чем дольше перебор, тем больше шансов на то, что взломщик будет обнаружен. Данная концепция компоновки на этапе установки не мешает кому-то сломать исполняемый файл. Она предназначена для того, чтобы хакер(ы) потратили больше усилий и придумали что-то более сложное.

Благодарности

Я признателен за замечания:

• Дэвиду Литчфилду (David Litchfield) и другим сотрудникам Next Generation Security Software Ltd
• Дэвиду Ахмаду (David Mirza Ahmad), Symantec
• Николасу Уиверу (Nicholas Weaver), Silicon Defense и UC Berkeley EECS

Комментарий переводчика

Забавно, как иногда преобразуются идеи. Когда-то схожая идея по модификации кода была применена в полиморфных вирусах, чтобы прятаться от антивирусов (хотя модификации в коде там, конечно, поизощреннее, да и размеры далеко не всегда такие, чтоб позволить себе роскошь собираться из несколькох obj-фалов). Теперь сходная идея предлагается для того, чтобы программы прятались от вирусов. Антивирусники справились с ней тогда, думается, что и вирусы справятся с ней сегодня. Впрочем, как дополнительный слой защиты - почему бы и нет?

обсудить  |  все отзывы (18)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[24309; 4; 8]