Личный блог Suvan`a.

Работая и играя с Linux... И что из этого иногда получается.

Обнаружение переполнения буфера.

Рубрика: Безопасность -> Укрепляем Linux
Метки: | | |
Воскресенье, 7 июня 2009 г.
Просмотров: 5383

     Функции ASLR очень полезны, но они не гарантируют 100% защиты - не­смотря на то, что применяется рандомизация, теоретически существует вероятность переполнения буфера.

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

     Для предотвращения возможности изменения хакером размеще­ния памяти в ASLR-защищенном процессе надо задать ограничение на количество перезапусков демона за определенный период времени.

     Для данного может употребляться утилита Segvguard, доступная по адресу: ftp://ftp.pl.openwall.com/misc/segvguard/. Segvguard состоит из двух частей:


  • Модуль ядра.
  • Пользовательский демон (segvdaemon).

     Модуль перехватывает сигналы SIGSEGV, SIGKILL, SIGBUS и SIGILL, временно помещая процесс в состояние TASK_UNINTERRUPTIBLE (непрерываемая задача). Затем модуль сообщает демону segvdaemon о пере­хваченном сигнале и ожидает от демона дальнейших инструкций.

Принятие решения о том, что сделать с потенциальной атакой, передано демону segvdaemon. На данное время Segvguard считает опасны­ми следующие ситуации:

  • Крах SUID-процесса.
  • Крах процесса, при котором ID пользователя, вызвавшего крах процесса, совпадает с ID владельца процесса.
  • Крах процесса с UID=0 (то есть, если владельцем процесса является root).
  • Крах интернет-сервиса.

     В случае с интернет-сервисом segvdaemon запрещает дальнейшее выполнение этого сервиса. Если крах потерпел SUID-процесс и хакер зарегистрирован в локальной системе (вошел в систему), пользователю будет запрещено исполнять данное приложение. Кроме того, если пользо­ватель попытается выполнить системный вызов setuid (ID хакера), он больше не сможет зайти в систему.

     Даже если не используется РаХ, инструменты вроде Segvguard все еще полезны, то есть не надо думать, что, если не установлен РаХ, толку от Segv­guard не будет. StackGuard, например, предоставляет два различных ре­жима защиты: обычный и MemGuard. MemGuard заметно медленнее, чем обычный способ, но зато он предоставляет более качественную защиту.

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

     Нужно понимать, что хакер может употреблять crash-детекторы (вроде Segvguard), чтобы остановить сервисы. Ведь в случае атаки Segvguard блокирует атакуемый сервис. Причем он блоки­руется не на определенное время, а до тех пор, пока администратор не разре­шит его выполнение. А если администратор отсутствует на рабочем месте, то выполнение сервиса может быть остановлено на долгое время.

     Хотя в документации Segvguard описана функция ограничения на коли­чество перезапусков сервисов (например, максимум три перезапуска за 10 минут), эта функция до сих пор не реализована. Учитывая относительно небольшой размер и простоту пользовательского демона segvdaemon, можно самостоятельно реализовать эту функции. Конечно, это не выход, но лучше, чем вообще обходиться без этой функции.

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