борьба с переполнением буффера: LIBSAFE

•	Главная
•	Архив новостей
•	Безопасность в Unix
•	Безопасность в Windows
•	Сборник FAQ'ов
•	Телефония, фрикинг
•	Кредитные карты
•	Криптография
•	Истории о хакерах
•	Программы, утилиты

_el@sp.sz.ru

борьба с переполнением буффера: LIBSAFE

Team Void

Использование переполнения буффера в стеке процесса позволило успешно осуществить большое количество успешных атак в прошлом году. Компания Bell-Labs представляет новый метод борьбы с такими атаками - который не требует ни рекомпиляции существуемого программного обеспечения, ни доступа к исходному коду защищаемых от переполнения программ. Новое средство никак не влияет на функциональность защищаемого программного обеспечения, за исключением того, что libsafe перехватывает все вызовыЮ и работает на уровне перехвата всех совершаемых программной вызовов функций.

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

Инсталляция библиотеки не представляет собою чего-то сдожного (стандартный процесс), а потом в файле .profile ставится ссытка на библиотеку и на процессы, ей контролируемые.

Пример того, чем оборачивается попыта некогда грозного переполнения буффера - ниже. Как вы видите, для системы это не полный выход из-под контроля, а лишь пара новых строчек в лог-файлах. Всей группе процессов будет послаг сигнал sigkill:

Dec 21 13:57:40 denver libsafe[15704]: Detected an attempt to write across stack boundary. Dec 21 13:57:40 denver libsafe[15704]: Terminating /users/ttsai/work/security.D0_2/test/t91 Dec 21 13:57:40 denver libsafe[15704]: scanf()

По причинам безопасности, динамический загрузчик не образает внимания на переменные LD_PRELOAD, при исполнении suidных программ. Но всё же на Linux-платформах вы можете использовать libsafe для контроля выполнения суидных программ, используя один их методов, описанных ниже:

Вы можете добавить путь к libsafe.so.1 в /etc/ld.so.preload, вместо использования переменной LD_PRELOAD. Если вы воспользуетесь этим методом, будьте уверены, что вы проинсталлировали libsafe.so.1 в корневой файловой системе, к примеру - в /lib, как это было делается при инсталляции по умолчанию. Используя папку, недоступную во время загрузки системы, (/usr/local/lib), вы можете только создать себе проблемы при следующей перезагрузке. Так же будьте осторожны, удаляя libsafe из /etc/ld.so.preload, когда ставите новую версию.

Если у вас имеется версия ld.so, которая новее, чем 1.9.0, вы можете установить LD_PRELOAD только лишь в базоваое имя libsafe.so.1 без полного пути. Затем, если файл расположен в папках библиотек (/lib /usr/lib), то система работает нормально и для suidных приложений.

ИСПОЛЬЗОВАНИЕ LIBSAFE

После того, как libsafe установлено, и LD_PRELOAD или же /etc/ld.so.preload были сконфигурированы верно, ничего не требуется делать. Процессы теперь отслеживаются, и уровень локальной безопасности системы повышен. Все подозрительные действия фиксируются в /var/log/secure. Вдобавок, если libsafe сконфигурировано с опцией NOTIFY_WITH_MAIL, то оно будет отсылать почту с сообщением о подозрительном происшествии.

КАК ОНО РАБОТАЕТ

Программы, написаные на языке С всегда страдали от переполнений буффера. Тому есть две причины - во-первых, язык программирования С не содержит встроеных рутин проверки предела ввода и указателей. Во вторых (что более важно), многие из функций, доступных в стандартном наборе функций языка С теоритически небезопасны. Итак, ответственность за их непроверенное использование целиком ложится на плечи программиста.

Libsafe использует новый метод для обнаружения данных критических ситуаций - переполнений буффера. Без наличия исходного кода данная библиотека "прозрачно" защищает процессы от переполнения стека. Методика перехвата всех вызовов библиотченых функций, которые уязвимы для переполнений и осуществляет сверку возвратных адресов после отработки процедуры.

Ключевая идея - возможность предсказвать безопасный верхний предел размера буффера автоматически. Данное приближение не может быть выполнено во время сборки, поскольку в этот момент просто-напросто невозможно определить его максимальный размер. Но вычисление размера буффера может быть произведено перед стартом функции, в которой производится доступ к данному буфферу. Предлагаемый метод способен определить максимальный размер буффера путём вычисления конца текущего конца фрейма стека. Затем представляется возможным сравнить количество данных, записываемых в буффер с его вычисленной длиной. Потэтому возвратный адрес не будет перезаписан - такая попытка будет отловлена задолго до "непоправимых событий". САЙТ ПРОИЗВОДИТЕЛЯ.
duke.