| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
Причины существования уязвимостей в UNIX-системах (Параграф из книги "Атака через Интернет") Рассмотрев выше достаточно много фактического материала, мы коснемся причин, по которым описанные нарушения безопасности UNIX имели место, и попытаемся их классифицировать. Сразу оговоримся, что эта классификация ни в коей мере не претендует на новизну или полноту - кому интересна эта тема, предлагаем обратиться к более серьезным научным работам [9, 23]. Здесь же мы опишем вполне понятные читателю причины, по которым, тем не менее, происходит до 90% всех случаев вскрытия 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, таких как асинхронное
выполнение процессов, развитый командный язык и файловая система, злоумышленниками
могут быть использованы механизмы подмены одного субъекта или объекта другим.
Например, в рассмотренных выше примерах часто применялась замена имени
файла, имени получателя и т. п. именем программы И последнее - нельзя приуменьшать роль человека при обеспечении безопасности любой системы. Возможно, он даже является слабейшим звеном. Про необходимость выбора надежных паролей уже говорилось. Неправильное администрирование - такая же актуальная проблема, а для UNIX она особенно остра, т. к. сложность администрирования UNIX-систем давно уже стала притчей во языцех и часто именно на это упирают конкуренты. Но за все надо платить, и это обратная сторона переносимости и гибкости UNIX. Более того, если говорить о слабости человека, защищенные системы обычно отказываются и еще от одной из основных идей UNIX — наличия суперпользователя, имеющего доступ ко всей информации и никому не подконтрольного. Его права могут быть распределены среди нескольких людей: администратора персонала, администратора безопасности, администратора сети и т. п., а сам он может быть удален из системы после ее инсталляции. В результате вербовка одного из администраторов не приводит к таким катастрофическим последствиям, как вербовка суперпользователя. Настройки некоторых приложений, того же sendmail, настолько сложны, что для поддержания работоспособности системы требуется специальный человек - системный администратор, - но даже он, мы уверены, не всегда знает о всех возможностях того или иного приложения и о том, как правильно их настроить. И если хакеры смогли проникнуть в систему, то это не всегда говорит о халатности администратора, а, зачастую, о его ограниченном знании того или иного продукта. |
|
| ||||||||||||||||
|