LINUX.ORG.RU

Критическая уязвимость в glibc (CVE-2015-0235)

 ,


3

3

Сегодня была обнаружена и успешно исправлена чрезвычайно опасная уязвимость в стандартной библиотеке glibc. Она заключалась в переполнении буфера внутри функции __nss_hostname_digits_dots(), которую, в частности, используют такие известные функции glibc как gethostbyname() и gethostbyname2(). В худшем для пользователя случае на уязвимой системе злоумышленник может добиться выполнения произвольного кода.

Проблема была исправлена коммитом еще в 2013-м году в glibc 2.18, однако многие дистрибутивы еще не успели перейти на эту версию. Сообщается, что самая ранняя уязвимая версия — 2.2 от 10 ноября 2000. В числе прочих уязвимыми оказались дистрибутивы RHEL 5.x, 6.x и 7.x.

Для большей уверенности и проверки своей системы вы можете воспользоваться небольшой утилитой, предложенной самими исследователями, текст которой (на C) можно взять на Github:

wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c
gcc gistfile1.c -o CVE-2015-0235
./CVE-2015-0235

Нашедшие уязвимость хакеры из Qualys уже присвоили ей кодовое имя GHOST. Сейчас они вплотную подошли к написанию боевого модуля к Metasploit.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 6)

Кажется, тут наметился срачик по поводу открытых исходников.

Я скажу вот что. Из многочисленных наблюдений мне стало понятно, что открытый код - это, с одной стороны, благо, с другой зло. Благо - что многие программы развиваются лучше (форки не в счёт, форки хуже раковых клеток, пожалуй). Минус - эти программы не гуёвые. Форки медиаплееров и прочего домашнего задания программистов не в счёт. Открытость кода губит большие профессиональные проекты.

Далее. Безопасность открытых проектов - иллюзия. ОШИБКИ находятся правятся только разработчиками проектов. Ткните меня носом в пример, когда в багзилле пипл (рядовой) открыл тикет с описанием CVE и примером кода (файл, строчка, функция). Из сторонних мне известна только PVS STUDIO.

full_inu
()

для 7 дебиана есть уже обновления?

ky4k0b
()
Ответ на: комментарий от full_inu

bleeding-edge

21 месяц назад

Я запомню это чудное мгновенье.

Вы ещё забыли про embedded-сектор, где понятие bleeding-edge и на более, чем 10 лет растянутся может.

ref: http://youtu.be/gFP5YcvQsKM (актуально всё ещё не пофикшено)

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)
pinkbyte@phantom ~ $ eix -c ^glibc$
[I] cross-armv6j-hardfloat-linux-gnueabi/glibc [1] (2.19-r1(2.2)@31.07.2014): GNU libc6 (also called glibc2) C library
[I] cross-mips64-unknown-linux-gnu/glibc [1] (2.20-r1(2.2)@06.01.2015): GNU libc6 (also called glibc2) C library
[I] sys-libs/glibc (2.19-r1(2.2){tbz2}@31.08.2014): GNU libc6 (also called glibc2) C library

Окэй, вздохнул с облегчением

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от anonymous

Основная идея *nix-систем замышлялась как деплой, портируемость и мобильность за счет компиляции исходного кода, а не засилье бинарщины.

Это не какая-то символическая плата за какие-то весьма спорные удобства (ибо пакетный ад всё ещё существует), это:

1) экономия электричества и времени на компиляциях (согласитесь, чайник сам себе пришивку не скомпилирует и не обновит, а если и обновит, то процессор у него должен быть огого);

2) компиляция кода несёт бинарники в массы. Неожиданно, да?

засилье бинарщины

full_inu
()

Дебиан 7 был уязвим. Обновился, теперь норм.

MrClon ★★★★★
()

так дыра удаленная или локальная?

rogerw
()
Ответ на: комментарий от full_inu

бинарщина - вот это действительно сомнительные удобства

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

Бинарщина - зло. В идеале, когда обновление это некий скрипт, который легко может быть установлен или его байткод сгенерированный на месте на устройство без его остановки и замены.

anonymous
()
Ответ на: комментарий от full_inu

конечно, кто спорит? Только генерация из исходников по месту.

anonymous
()
Ответ на: комментарий от dexpl

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

root@localhost [~]# yum update
Loaded plugins: fastestmirror, presto
Setting up Update Process
Loading mirror speeds from cached hostfile
 * base: ftp.estpak.ee
 * extras: ftp.estpak.ee
 * updates: ftp.estpak.ee
No Packages marked for Update
root@localhost [~]# rpm -qa | grep glibc
glibc-static-2.12-1.149.el6_6.4.x86_64
glibc-headers-2.12-1.149.el6_6.4.x86_64
glibc-common-2.12-1.149.el6_6.4.x86_64
glibc-devel-2.12-1.149.el6_6.4.i686
glibc-2.12-1.149.el6_6.4.i686
glibc-devel-2.12-1.149.el6_6.4.x86_64
glibc-2.12-1.149.el6_6.4.x86_64

Mr_Alone ★★★★★
()
Последнее исправление: Mr_Alone (всего исправлений: 1)

У меня давно 2.20. Как там дебьянщики с их принципом «старее - штабильнее»?

Meyer ★★★★★
()
Ответ на: комментарий от Mr_Alone

Setting up Update Process

Прочитал как Setting up Lennart Process...

Пора завязывать, да.

full_inu
()
Ответ на: комментарий от Mr_Alone

Он появился минут 20 назад.

└► date --date="2015-01-27 14:35:45 EST"
Вт янв 27 22:35:45 MSK 2015

Больше часа, вообще-то. А .src.rpm — вообще на той неделе, если ftp://ftp.redhat.com не врет (и судя по changelog'у пакета, он таки не врет).

dexpl ★★★★★
()
Последнее исправление: dexpl (всего исправлений: 1)
Ответ на: комментарий от karton1

Зато под винду 0day уязвимости месяцами ходят по закрытым форумам, только потом попадают в открытый доступ. И только через некоторое время наступает четверг патчей у MS, да-да.

X10Dead ★★★★★
()
Последнее исправление: X10Dead (всего исправлений: 1)
Ответ на: комментарий от karton1

Я тебе на пальцах объясню:

Linux. Два часа назад у меня уже все обновилось и я теперь полностью в безопасности (а я еще удивлялся, чего это все либСи начали обновлятся).

Windows. После того как все ресурсы уже обсудили что мелкомягкие не смогли за три месяца осилисть патч проходит три дня и они «срочно» выпускают обновление.

trex6 ★★★★★
()

Решето, причём селинукс эти баги не лечит.

Napilnik ★★★★★
()
Ответ на: комментарий от full_inu

Думаю, вообще по боку, куда важнее, стоит ли за проектом какая фирма, согласная вбухивать туда деньги. Открытый код очень на руку, когда это базовые либы и софт/ЯП, без открытого кода сегодня никто наживку не сожрет. Это просто гарантия, что тебя в определенный момент не «дернут за крючок». В прикладном софте открытый код дает мало реального профита. Ну есть открытый гимп, его как пилили 2 с половиной анонимуса, так и пилят уже 18 лет. И есть куча опенсурсного софта, который сдохнет в тот же день, когда автора переедет автобус. Куда важнее для пользователя открытые и максимально простые форматы сохранения документов, чтобы и через 20 лет еще прочитать можно было без проблем.

ptarh ★★★★★
()
Ответ на: комментарий от full_inu

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

Запросто — CVE-2015-0235. «Хакеры из Qualys» — вполне рядовой пипл, не имеющий отношения к разработке glibc.

dexpl ★★★★★
()

обнаружили вчера, а исправили 2 года назад. ок.

ass ★★★★
()

однако многие дистрибутивы еще не успели перейти на эту версию

ну и что, зато стабильно

anonymous
()
Ответ на: Not vulnerable от Axon

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

anonymous
()

Пора переходить на Mezzano! Будущее за лиспом, товарищи!

Deleted
()
Ответ на: комментарий от full_inu

Безопасность открытых проектов - иллюзия

Скорее открытые проекты — другой способ внедрения дыр.

Во-первых, почти весь GNU софт — трудно читаемый и очень долго компилируемый. Может, по-другому не умеют.

Во вторых, сильно завязан друг-на-друга. То есть текущий glibc для сборки требует текущий gcc, текущий gcc требует свежую glibc и тд, и тп. Так что усидеть на нестрандартной конфигурации — нетривиальная задача. И в основном все меняют софт по команде, у всех софт примерно одинаков.

В-третьих, как ловко используют уязвимости. Такого даже специально трудно добиться. А когда все бредят про безопасность уже сколько лет, и однако это не помогает — ссылки на то, что дыры возникли сами по себе, не убеждают.

Относительно subj — код написан сложно, запутанно.

if (buffer_size == NULL)
...
else if (buffer_size != NULL && *buffer_size < size_needed)
Зачем нужна вторая проверка buffer_size ?

Смотрим patch для исправления уязвимости, который спокойно наложился и на glibc-2.5

      if ((isxdigit (name[0]) && strchr (name, ':') != NULL) || name[0] == ':')
        {
-         const char *cp;
-         char *hostname;
-         typedef unsigned char host_addr_t[16];
-         host_addr_t *host_addr;
-         typedef char *host_addr_list_t[2];
-         host_addr_list_t *h_addr_ptrs;
-         size_t size_needed;
-         int addr_size;
-
Тут целая куча лишних переменных. И она всё же тут торчала 14 лет?

PS: в gnu-софте нет персональной ответственности, нет разборок: кто вёл проект, кто залил, кто проверял-одобрял commit.

seyko2
()

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

aplay ★★★★★
()
Ответ на: комментарий от ZenitharChampion

А у тебя что-то с роутера во вне открыто?
Ну там веб-морда или telnet/ssh?
Тогда нужно. Если, конечно, прошивку выкатят.

Yustas ★★★★
()

Спасибо за тест, проверился, обновил свои сервачки.

Ghostwolf ★★★★★
()
Ответ на: комментарий от karton1

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

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

backspace
()
wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c

gcc gistfile1.c -o libcerr

./libcerr
vulnerable

Как страшно жЫть!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от full_inu

А в проприетарщине вообще годами баги висят и никому до них дела нет!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от ptarh

18 лет уже отработано и в этом суть, он вполне выполняет свои задачи, гимп-то

backspace
()
Ответ на: комментарий от Eddy_Em

Хотя, чего удивляться, если я не обновляюсь с конца 2012-го года?

pacman -Q glibc
glibc 2.17-3
Жду, пока совсем сдохнет мой арчик. Тогда и поставлю на работе гентушечку.

Eddy_Em ☆☆☆☆☆
()
Ответ на: Безопасность открытых проектов - иллюзия от seyko2

Во-первых, почти весь GNU софт — трудно читаемый и очень долго компилируемый. Может, по-другому не умеют.

по сравнению с закрытым софтом код обычно на порядок лучше.

Тут целая куча лишних переменных. И она всё же тут торчала 14 лет?

ты б видел какой-нить закрытые проект, которому 14+ лет — ужаснулся бы.

PS: в gnu-софте нет персональной ответственности, нет разборок: кто вёл проект, кто залил, кто проверял-одобрял commit.

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

anonymous
()
Ответ на: комментарий от Eddy_Em

Жду, пока совсем сдохнет мой арчик. Тогда и поставлю на работе гентушечку.

ты ее до сих пор не собрал?

anonymous
()
Ответ на: комментарий от anonymous

Почему же? В чруте уже больше полутора лет болтается. Периодически (раз в 1-2 недели) обновляю, перетаскиваю по сетке бинари на домашний и там делаю emerge -uDNK world.

А на работе пока не могу: это ж не меньше недели будут "скрытые косяки" проявляться (то модуль ведра какой забыл скомпилять, то какую-нибудь полезную софтинку поставить — вот, вчерась обнаружил, что asoundconf'а нет, благо, из арчика удалось перетащить).

Eddy_Em ☆☆☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.