BugTraq.Ru
Русский BugTraq
http://www.bugtraq.ru/library/programming/diversify.html

Разнообразие ради выживания. Популяция из различных исполняемых модулей с одинаковой функциональностью.
Yinrong Huang, перевод - Дмитрий Леонов
Опубликовано: dl, 04.02.03 14:28
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'у, нацеленная на определенный исполняемый модуль, потеряет свою эффективность в случае другого исполняемого модуля из-за измененного распределения адресов (к сожалению, при этом она может испортить приложение).

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

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

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

Замечания

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

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

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

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

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

обсудить  |  все отзывы (18)

[24291; 4; 8]




  Copyright © 2001-2024 Dmitry Leonov Design: Vadim Derkach