Как стать автором
Обновить

Комментарии 11

Увлекательно.

Интересно, а что всё-таки делает добавленный в ssh ключик "-G"?
Illigal option же, такой ключ не предусмотрен ни в оригинальном ssh, ни в зараженном. Только оригинальная ругается, а зараженная usage выводит.
Это-то я в тексте статьи видел, да. Но всё же, разбор аргументов командной строки — обычно довольно изолированный код, слабо завязанный на остальную программу. Едва ли такое поведение можно объяснить случайным побочным эффектом от изменений в совершенно другом месте.

Неужели авторы заражённой версии сделали это изменение просто так и никаких подводных камней за этим ключём нет?
Исходники предыдущих версий еще нигде не всплывали?
А как все-таки зараженная библиотека попадает в систему?
make install от рута :)
полагаю, как большинство постороннего кода на серверах: виндовый троян утащил сохраненные пароли из ftp-клиента, или что-нибудь в таком духе.
BTW, можно использовать grep -q, вместо перенаправления в /dev/null
Опасная тенденция. У меня как-то давно была подобная идея… собирать код из других частей кода...., часть кодировать (как руки Мандрида из фильма ЛЕКС). Такую бяку сложно отловить при проникновении, она мимикрирует под обычную программу, а потом начинает обратать щупальцами, прячась и претворяться мертвой. Но я думаю это всё только цветочки.
Даже не могу себе представить как бы я себя почувствовал увидев «System infected»
вот такой вывод у меня на всех машинах, «скрипт» определяет его как «System clean», но все равно странно, что об этом не написано в статье
$ ssh -G
ssh: illegal option — G
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command]


CentOS 6, Ubuntu 10.04, Debian 7
Зарегистрируйтесь на Хабре, чтобы оставить комментарий