Все о Linux. LinuxRSP.Ru


Cвежие новости Linux и BSD, анонсы статей и книг прямо в почтовый ящик!
Подписаться письмом


 Сегодняшние новости:

25 лет исполнилось ядру Linux

Релиз KDevelop 5.0

Oracle открывает код JDK9 для ARM

Выпущен Timewarrior 1.0.0

Релиз Android 7.0

Percona Memory Engine для MongoDB на базе WiredTiger

PowerShell открыт и доступен для Linux

Форк TrueCrypt: VeraCrypt 1.18

Релиз Snapcraft 2.14

Релиз Go 1.7

Стабильный выпуск рабочего стола Lumina

Вышла первая версия аналога OpenCV - DCV 0.1

Выпуск минималистичной программы для мониторинга jsonmon 3

В MIT разработали новый язык программирования

Первый релиз Qt5Gtk2

Godot 2.1 - новая версия открытого игрового движка

Свободная цифровая станция звукозаписи: Ardour 5.0

Обновление SkypeWeb Plugin for Pidgin

Вышла версия 3.0 Android File Transfer для Linux (и для OS X)

Программный аналог MIDI-контроллера для создания музыки: Launchpadd v1.3

Mozilla спонсирует поддержку Python 3.5 в PyPy

Ef 0.08 - программа для моделирования динамики заряженных частиц

Обновление текстового редактора TEA до версии 42.0.0

Релиз OpenOrienteering Mapper 0.6.4

Вышли Guix и GuixSD 0.11

Релиз Opera 39

Выпуск LibreOffice 5.2

В OpenSSH обнаружены и устранены некоторые уязвимости

Эмулятор FCEUX 2.2.3

Компания Билайн переходит на российскую СУБД с открытым исходным кодом Tarantool

Google

 Новые статьи :

Утилиты для восстановления потерянных данных в Linux

Лучшие файловые менеджеры для Android

20 лучших бесплатных книг о Linux

Как сгенерировать открытый/закрытый SSH-ключ в Linux

Grive - клиент Google Drive для Linux с открытым исходным кодом

Протокол IPv6: варианты подключения

Сервер из образа: DHCP + TFTP + Initrd + OpenVZ

Обзор веб-панелей управления хостингом

Приёмы работы с Vim

Nginx как Reverse Proxy для сайта, использующего SSL

Разработка модулей ядра Linux

Мониторинг нагрузки http-сервера Apache 2

Перевод комментариев к файлу конфигурации Squid

Решение проблем при использовании "1c предприятие" 8.2 в Linux

Advanced Bash-Scripting Guide Искусство программирования на языке сценариев командной оболочки







Rambler's Top100





 
 

Причины существования уязвимостей в UNIX-системах

(Это параграф из книги "Атака через Интернет")

Рассмотрев выше достаточно много фактического материала, мы коснемся причин, по которым описанные нарушения безопасности UNIX имели место, и попытаемся их классифицировать. Сразу оговоримся, что эта классификация ни в коей мере не претендует на новизну или полноту - кому интересна эта тема, предлагаем обратиться к более серьезным научным работам [9, 23]. Здесь же мы опишем вполне понятные читателю причины, по которым, тем не менее, происходит до 90% всех случаев вскрытия UNIX-хостов.

  1. Наличие демонов.
  2. Механизм SUID/SGID-процессов.
  3. Эти механизмы, являющиеся неотъемлемой частью идеологии UNIX, были и будут лакомым кусочком для хакеров, т. к. в этом случае пользователь всегда взаимодействует с процессом, имеющим большие привилегии, чем у него самого, и поэтому любая ошибка или недоработка в нем автоматически ведет к возможности использования этих привилегий.

  4. Излишнее доверие. Об этом уже достаточно говорилось выше. Повторим, что в UNIX достаточно много служб, использующих доверие, и они могут тем или иным способом быть обмануты.
  5. К этим трем причинам нельзя не добавить следующую:

  6. Человеческий фактор с весьма разнообразными способами его проявления - от легко вскрываемых паролей у обычных пользователей до ошибок у квалифицированных системных администраторов, многие из которых как раз и открывают путь для использования механизмов доверия.

Рис. 8.2. Причины уязвимости UNIX при атаках на телекоммуникационные службы.

Рассмотрим теперь более подробно причины, по которым оказываются уязвимы демоны и SUID/SGID-процессы:

  1. возможность возникновения непредусмотренных ситуаций, связанных с ошибками или недоработками в программировании;
  2. наличие скрытых путей взаимодействия с программой, называемых "люками" ;
  3. возможность подмены субъектов и объектов различным образом.

К первым можно отнести классическую ситуацию с переполнением буфера или размерности массива (примеры см. п. 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, настолько сложны, что для поддержания работоспособности системы требуется специальный человек - системный администратор, - но даже он, мы уверены, не всегда знает о всех возможностях того или иного приложения и о том, как правильно их настроить. И если хакеры смогли проникнуть в систему, то это не всегда говорит о халатности администратора, а, зачастую, о его ограниченном знании того или иного продукта.═



      

Связь | О проекте LinuxRSP | Реклама | О Linux
© 1999-2017 LinuxRSP