Технологии для отражения неизвестных атак: часть первая - Программная изоляция ошибки

Защита, базирующаяся на современном антивирусном обеспечении, дополненная разумной фильтрацией (отсеиванием всех выполняемых компонентов в электронной почте и web-трафике), используя системы межсетевой защиты, при условии своевременной установки защитных заплат, неплохо справляется с известными классами вирусов, червей и вредных скриптов. Отлично отфильтровываются как обычные инфицированные файлы, так и почтовые черви, выполняемые скрипты и большинство других вирусов, основанных на старых брешах в защите. Но, к сожалению, все эти защитные системы практически бесполезны против так называемых активных червей с оптимизированной скоростью распространения (speed-optimized active worm), основанных на ранее неизвестных брешах в защите.

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

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

Программная изоляция ошибки

Первая технология - Программная Изоляция Ошибки (Software Fault Isolation - SFI), разработана Вахби (Efficient Software Based Fault Isolation, на Proceedings of the Symposium on Operating System Principles, 1993). Это механизм создания java-подобных ограниченных сред (т.н. sandboxes) для динамической загрузки произвольных кодов, независимым от языка способом. В отличие JVM-систем, он может применяться независимо от исходного языка и компилятора. Единственное семантическое ограничение - динамическая генерация кода не позволяется в пределах изолированного ошибкой модуля.

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

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

Конечно, из-за непрерывного контроля над всеми операциями, ухудшается производительность работы. Но, как показали исследования, время, необходимое для выполнения программ, вырастает не так уж и критически – всего на восемь-десять процентов. К тому же, при испытаниях более поздних версий SFI, уже сообщается о «торможении» всего на пять процентов времени, по сравнению с незащищенными системами. Причем сообщается, что использование компилятора C или C ++ оказывается более предпочтительным по производительности, чем большинства систем Java, при поддержании одинакового уровня защиты. Поскольку методика SFI не требует привязки к конкретному приложению, то она может использоваться для защиты самых разных систем.

Эта методика предоставляет два существенных преимущества: позволяет безопасное выполнение произвольных модулей (даже содержащихся в ActiveX и дополнениях к браузеру и являющихся наиболее опасными, в то время как Microsoft и другие компании сосредоточились на системах идентификации, и совсем забыли о таких системах изоляции), и предотвращает наиболее разрушительные эффекты переполнения буфера: способность выполнять произвольный код. Если изолированный модуль содержит переполнение буфера, хакер ограничен лишь возможностью перезаписи данных в модуле и запуском разрешенных в модуле программ, что устраняет большинство возможностей, содержащихся в нападениях методом переполнения буфера.

К примеру, если бы IIS использовал этот метод защиты в своих модулях и сценариях, то, несмотря на неизвестный на тот момент прокол в защите, эта система смогла бы справиться с Code Red (то, чего не смогли сделать летом 2001 года практически все новейшие антивирусные и другие защитные системы). Без способности вводить произвольный код в другой модуль, Code Red был бы неспособен размножаться. Также, SFI предотвратила бы использование захваченного секретного ключа Microsoft для создания основанных на ActiveX саморазмножающихся червей, потому что загруженные ActiveX модули были бы сразу же успешно изолированы.

Метод Программной Изоляции Ошибки был разработан и запатентован компанией Colusa Software с 1994 по 1996 год, как часть их структуры кода OmniWare - средства безопасного выполнения кода, независимого от языка программирования и архитектуры. Но в марте 1996 компания Colusa был «куплена на корню» корпорацией Microsoft и включена в свою структуру для предотвращения распространения конкурирующей Java-подобной системы кода. С тех пор, были сведения о продолжении разработок, уже в составе Microsoft, но до сих пор они не вылились в интеграцию с каким-либо изделием крупнейшей корпорации. А жаль, система интересная и многообещающая.

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

Но вот в марте будет уже шесть лет, как права на эту технологию принадлежат Microsoft, а результатов ее применения в программах корпорации мы не видим. Единственное, что мы наблюдаем – все новые и новые проблемы с переполнением буфера и другими дефектами защиты, от которых можно было бы легко избавиться…

по материалам securityfocus.com