 |
8.7. Причины существования уязвимостей в UNIX-системах
Рассмотрев выше достаточно много фактического
материала, мы коснемся причин, по которым
описанные нарушения безопасности UNIX имели место,
и попытаемся их классифицировать. Сразу
оговоримся, что эта классификация ни в коей мере
не претендует на новизну или полноту - кому
интересна эта тема, предлагаем обратиться к
более серьезным научным работам [9, 23]. Здесь же мы
опишем вполне понятные читателю причины, по
которым, тем не менее, происходит до 90% всех
случаев вскрытия UNIX-хостов.
- Наличие демонов.
- Механизм SUID/SGID-процессов.
Эти механизмы, являющиеся неотъемлемой частью
идеологии UNIX, были и будут лакомым кусочком для
хакеров, т. к. в этом случае пользователь всегда
взаимодействует с процессом, имеющим большие
привилегии, чем у него самого, и поэтому любая
ошибка или недоработка в нем автоматически ведет
к возможности использования этих привилегий.
- Излишнее доверие.
Об этом уже достаточно говорилось выше.
Повторим, что в UNIX достаточно много служб,
использующих доверие, и они могут тем или иным
способом быть обмануты.
К этим трем причинам нельзя не добавить
следующую:
- Человеческий фактор с весьма разнообразными
способами его проявления - от легко
вскрываемых паролей у обычных пользователей до
ошибок у квалифицированных системных
администраторов, многие из которых как раз и
открывают путь для использования механизмов
доверия.
Рис. 8.2. Причины уязвимости UNIX
при атаках на телекоммуникационные службы.
Рассмотрим теперь более подробно причины, по
которым оказываются уязвимы демоны и SUID/SGID-процессы:
- возможность возникновения непредусмотренных
ситуаций, связанных с ошибками или недоработками
в программировании;
- наличие скрытых путей взаимодействия с
программой, называемых "люками" ;
- возможность подмены субъектов и объектов
различным образом.
К первым можно отнести классическую ситуацию с
переполнением буфера или размерности массива
(примеры см. п. 8.4.1.2 и 8.6.2), ведущую к затиранию
области стека и записи туда специальных команд,
которые будут затем исполнены. Заметим сразу, что
этот способ, несмотря на свою популярность,
всегда будет системозависимым и ориентирован
только на конкретную платформу и версию UNIX.
Хорошим примером непредусмотренной ситуации в
многозадачной операционной системе является
неправильная обработка некоторого специального
сигнала или прерывания. Часто хакер имеет
возможность смоделировать ситуацию, в которой
этот сигнал или прерывание будет послано (в UNIX'е
посылка сигнала решается очень просто - командой
kill - см. пример 8.6.2).
Наконец, одна из самых распространенных
программистских ошибок - является неправильная
обработка входных данных (это является некоторым
обобщением случая переполнения буфера.) По
свидетельству [24], ими в 1990 и 1995 годах были
подвергнуты автоматизированному тестированию
около 80 программ на 9 различных платформах UNIX -
специальная программа подавала на вход строки
длиной до 100000 символов. Результатом явилось то,
что 25- 33% в 1990 г. и 18- 23% в 1995 г. работали
некорректно - зависали, сбрасывали аварийный
дамп и т. п. (Интересно, что в коммерческих версиях
UNIX этот процент доходил до 43, тогда как в свободно
распространяемых он был меньше 10.) Впрочем,
справедливости ради надо отметить, что только 2
программы-демона вели себя таким образом в 1990 г.,
а через 5 лет эти ошибки были исправлены. Ну, а
если программа неправильно обрабатывает
случайные входные данные, то очевидно, что можно
подобрать такой набор специфических входных
данных, которые приведут к желаемым для хакера
последствиям. Примером этого может служить innd
(8.6.4).
Люком, или "черным входом" (backdoor) часто
называют оставленную разработчиком
недокументированную возможность взаимодействия
(чаще всего входа в систему), например, известный
только разработчику универсальный "пароль"
. Люки оставляют в конечных программах
вследствие ошибки, не убрав отладочный код или
вследствие необходимости продолжения отладки
уже в реальной системе в связи с ее высокой
сложностью или же их корыстных интересов. Люки -
это любимый путь входа в удаленную систему не
только у хакеров, но и у журналистов и режиссеров
вкупе с подбором "главного" пароля
перебором за минуту до взрыва, но в отличие от
последнего способа, люки реально существуют.
Классический пример люка - это, конечно,
отладочный режим в sendmail.
Наконец, вследствие многих особенностей UNIX,
таких как асинхронное выполнение процессов,
развитый командный язык и файловая система,
злоумышленниками могут быть использованы
механизмы подмены одного субъекта или объекта
другим. Например, в рассмотренных выше примерах
часто применялась замена имени файла, имени
получателя и т. п. именем программы
(см. 8.5.2.3 и 8.5.2.4.3). Аналогично может быть выполнена
подмена некоторых специальных переменных. Так,
для некоторых версий UNIX существует атака,
связанная с подменой символа разделителя команд
или опций на символ "/" . Это приводит к тому,
что когда программа вызывает /bin/sh, вместо него
вызывается файл bin с параметром sh в текущем
каталоге. Похожая ситуация возникает при атаке
на telnetd (см. 8.6.1). Наконец, очень популярным в UNIX
видом подмены является создание ссылки (link)
на критичный файл. После этого файл-ссылка
некоторым образом получает дополнительные права
доступа, и тем самым осуществляется
несанкционированный доступ к исходному файлу.
Аналогичная ситуация с подменой файла возникает,
если путь к файлу определен не как абсолютный
(/bin/sh), а относительный (../bin/sh или $(BIN)/sh). Такая
ситуация имела место в рассмотренной уязвимости
telnetd.
И последнее - нельзя приуменьшать роль человека
при обеспечении безопасности любой системы.
Возможно, он даже является слабейшим звеном. Про
необходимость выбора надежных паролей уже
говорилось. Неправильное администрирование -
такая же актуальная проблема, а для UNIX она
особенно остра, т. к. сложность администрирования
UNIX-систем давно уже стала притчей во языцех и
часто именно на это упирают конкуренты. Но за все
надо платить, и это обратная сторона
переносимости и гибкости UNIX. Более того, если
говорить о слабости человека, защищенные системы
обычно отказываются и еще от одной из основных
идей UNIX - наличия суперпользователя, имеющего
доступ ко всей информации и никому не
подконтрольного. Его права могут быть
распределены среди нескольких людей:
администратора персонала, администратора
безопасности, администратора сети и т. п., а сам он
может быть удален из системы после ее
инсталляции. В результате вербовка одного из
администраторов не приводит к таким
катастрофическим последствиям, как вербовка
суперпользователя.
Настройки некоторых приложений, того же sendmail,
настолько сложны, что для поддержания
работоспособности системы требуется
специальный человек - системный администратор, -
но даже он, мы уверены, не всегда знает о всех
возможностях того или иного приложения и о том,
как правильно их настроить. И если хакеры смогли
проникнуть в систему, то это не всегда говорит о
халатности администратора, а, зачастую, о его
ограниченном знании того или иного продукта.
|
