Защита от переполнения буфера

Flashback    Статьи и обзоры    

В Windows Vista появлись новые средства защиты от переполнения буфера и улучшены многие из имевшихся в Windows XP SP2 и Windows Server 2003 SP1. Прежде чем мы начнем обсуждение новой функциональности, необходимо сделать несколько важных замечаний. Во-первых, программист не освобождается от обязанности писать надежный код, это можно сравнить с ремнями безопасности в машине – ни одно из них не избавит вас от ошибок, но если хотя бы одно сработало, то у вас, определенно, возникли проблемы. Ни ремни безопасности (подушки безопасности, тормоза с антиблокировочной системой и т.п), никто другой не сможет гарантировать вам безоблачное существование, но если случилась неприятность, лучше иметь что-то, что предотвратит усугубление вредных последствий. Наш друг Йон Пинкус (Jon Pincus), исследователь из Microsoft Research, очень хорошо выразил этот принцип:”Достаточно сложная атака может преодолеть любое отдельное взятое средство защиты или набор таких средств. Любое эффективное средство защиты полностью предотвращает атаки определенного рода”.
Если вы написали особо “хитрую” программу, атакующую десяток различных брешей и запускающую произвольный код, несмотря на все предпринятые нами защитные меры, не обольщайтесь – вы не обнаружили ничего нового или оригинального. В любой программе в среднем содержится от 5 до 50 дефектов на 1000 строк кода. Вопрос о том, как правильно подсчитывать число дефектов в ПО, был предметом многих исследований и споров. Средний разработчик делает от 50 до 100 ошибок на тысячу строк кода. Многие из них обнаруживаются при компиляции и тестировании. Взаимный анализ кода разработчиками, обучение, наличие опыта и использование средств статического анализа обычно позволяют снизить число ошибок до нижней границы диапозона. Тестирование кода методом подачи на вход приложения случайных данных или, того лучше, целевое тестирование также помогает снизить число дефектов. К сожалению, в любом (за исключением самого простого) приложении практически невозможно свести числов дефектов до нуля, и чем ближе это чило к нулю, тем больше затрат требуется на дальнейшую очистку кода, поэтому часто лучше просто смириться с фактом, что в приложении будет некоторое число ошибок.
Часть имеющихся в коде дефектов поддаются эксплуатации, т.е могут использоваться для проведения успешных атак. Вместе с тем даже простейшие средства защиты способны полностью устранить риск проведения некоторых типов атак. Например, с появлением защиты стека больше невозможен успех атаки, основанной на перезаписи буфера стека со смещением на один байт вниз.