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 ()

РЕШЕТО

РЕШЕТО

anonymous ()

С 2.2 до 2.18 же

anonymous ()

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

Chaser_Andrey ★★★★★ ()

Удаленно что-нибудь умеет навредить?

hbars ★★★★ ()

в windows тоже должна быть

т.к. сорцы то одни

subwoofer ★★★★★ ()

Опенсорс,опенсорс.... Все твердят о безопасности.Вот вам и безопасность.

karton1 ★★★ ()

Not vulnerable

$ grep glibc /var/log/pacman.log | tail -n 1
[2014-12-29 01:05] [PACMAN] upgraded glibc (2.20-5 -> 2.20-6)
[2014-12-29 01:05] [PACMAN] upgraded lib32-glibc (2.20-4 -> 2.20-6)

ЧЯДНТ?

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

The GNU C Library - 15 лет на рынке решета!

P.S. Интересно, сколько дыр в бздшной libc...

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

ЧЯДНТ?

2.18 и новее не подвержены уязвимости.

proud_anon ★★★★★ ()

в Ubutnu 14.04 LTS с последними обновлениями not vulnerable. Gentoo тоже. Я сплю спокойно.

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

Лол, пока я писал коммент, новость успели отредактировать. Когда я её читал, в ней красовалась такая строчка:

Сообщается, что уязвимы все версии glibc, начиная с релиза 2.2 от 10 ноября 2000 года, то есть, говоря проще, все.

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

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

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

Лол, пока я писал коммент, новость успели отредактировать. Когда я её читал, в ней красовалась такая строчка...

Плюсую.

greek_31 ★★ ()
$ eix -cI glibc
[I] sys-libs/glibc (2.19-r1(2.2)@30.07.2014): GNU libc6 (also called glibc2) C library

Можно спать спокойно. На серверах обновлю...

UPD: дебианщикам (7.x) обновляться обязательно.

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

P.S. Интересно, сколько дыр в бздшной libc...

Open: undefined reference to `gethostbyname_r'

Free: should not happen

beastie ★★★★★ ()

CVE-2015-0235

$ aptitude changelog libc6

eglibc (2.13-38+deb7u7) wheezy-security; urgency=medium

  * debian/patches/any/cvs-gethostbyname.diff: new patch from upstream
    to fix a buffer overflow in gethostbyname (CVE-2015-0235).

Сплю дальше. :)

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: РЕШЕТО от anonymous
./CVE-2015-0235
not vulnerable
cli ()
Ответ на: комментарий от beastie

Ну я не только про гнутые расширения, в целом интересно.

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

wheezy починили, а squeeze-lts нет. Вот вам и стабильный дебилиан.

beastie ★★★★★ ()

Проблема была исправлена коммитом еще в 2013-м году в glibc 2.18...

Эх, а у меня в репозиториях 2.15 - максимум... пришло время переустанавливать линукс, однако.

segfault ★★★★★ ()
 ~  ./CVE-2015-0235 
not vulnerable
 ~  eix -e glibc
[I] sys-libs/glibc
     Available versions:  (2.2) ~2.9_p20081201-r3^s 2.10.1-r1^s 2.11.3^s ~2.12.1-r3^s 2.12.2^s ~2.13-r2^s 2.13-r4^s ~2.14^s ~2.14.1-r2^s 2.14.1-r3^s ~2.15-r1^s 2.15-r2^s 2.15-r3^s 2.16.0^s 2.17^s{tbz2} ~2.18-r1^s ~2.19^s 2.19-r1^s{tbz2} 2.19-r1^s{tbz2}[1] ~2.19-r1^s{tbz2}[2] ~2.20^s ~2.20-r1^s **9999^s

Дистрибутивопроблемы.

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

wheezy починили, а squeeze-lts нет. Вот вам и стабильный дебилиан.

oldstale (хоть и LTS) всегда с опозданием патчился.

Zubok ★★★★★ ()

Она заключалась в переполнении буфера

Вся суть языков, которые не способны в memory safety.

quantum-troll ★★★★★ ()
Ответ на: комментарий от beastie

Вот вам и стабильный дебилиан.

Именно стабильный. В stable всё уже закрыто. А про squeeze-lts никто и не обещал, что уязвимости будут устраняться так же быстро как в stable.

Polugnom ★★★★★ ()

Проблема была исправлена коммитом еще в 2013-м году в glibc 2.18, однако многие дистрибутивы еще не успели перейти на эту версию.

-rw-r--r-- 1 root root 330K янв 9 06:02 /var/log/packages/glibc-2.20-i486-2

Slackware

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

Именно стабильный. В stable всё уже закрыто. А про squeeze-lts никто и не обещал, что уязвимости будут устраняться так же быстро как в stable.

Да ее только сегодня закрыли. Возможно, что уже завтра закроют oldstable. Может, и сегодня уже.

Zubok ★★★★★ ()

О раньше opennet'а!

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

А про squeeze-lts никто и не обещал, что уязвимости будут устраняться так же быстро как в stable.

Изначально невенрый подход. (И в этом, к сожалению, весь дух опен-сыра.) Не все живут на bleeding-edge. Security-updates для lts — это чуть ли не первое, что должно делатся сразу после патча в upstream.

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

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

RedEyedMan4 ★★★★★ ()

По ссылке сказано, что чтобы воспользоваться уязвимостью, надо сформировать адрес, состоящий только из цифр и точек, и корректно распознаваемый функцией inet_aton как адрес IPv4, длиной более 1024 байт.

При этом есть несколько факторов, которые сильно снижают «критичность» уязвимости даже на уязвимых системах: во-первых, почти весь [поддерживаемый] софт использует getaddrinfo вместо устаревшей функции gethostbyname, во-вторых, многие программы (в особенности SUIDные) используют gethostbyname только если inet_aton вернул ошибку, а в этом случае уязвимость не возникает; ну и в-третьих, почти все остальные программы используют gethostbyname для проверки совпадения DNS-имен (double-reverse DNS check, похоже тут нет устоявшегося русскоязычного словосочетания) входящего запроса и результата обратного DNS запроса.

Короче говоря, проэксплуатировать эту уязвимость не так-то просто.

Kiborg ★★★ ()

решето

Проблема была исправлена коммитом еще в 2013-м году в glibc 2.18

Любители штабильности ССЗБ. У меня 2.20.

Klymedy ★★★★★ ()

Ну, кто там утверждал что сипроблемы это ерунда? Классическое переполнение, наверно программисты опять были не той квалификации, ага.

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

Не все живут на bleeding-edge

Какой нафиг bleeding-edge? Wheezy вышел 21 месяц назад.

Polugnom ★★★★★ ()

хым, у меня на дебиане стейбл стилл 2.0 вроде ещё)

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

На «долгоиграющих» серверах даже это может быть проблемой. У меня, например, есть ещё пару (более-менне критичных) squeezy серверов, на которых апдейт до wheezy ломает к чертям всё. Переустановка тоже проблематична, т.к. для програм, там крутящихся, уже недоступны зависимости. Вся надежда только на бекапы и «don't touch running system». И с этим приходится жить. Это вам не localhost.

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 3)
Ответ на: комментарий от emulek

2.20 только для Slackware-current, а в 14.1-2.15.

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

Доступность исходников не делает программу абсолютно безопасной. Над безопасностью нужно работать. В случае с опенсорсом, этим может заниматься любой желающий, что собственно и происходит. Тысячи разработчиков со всего мира латают проекты с открытыми исходниками. Тем не менее, открытые проекты всегда чуть-чуть безопасней по умолчанию, открывая исходники, разработчик в том числе говорит: «Ребзя, мне нечего скрывать! Я ничего против вас не замышляю!»

fero ★★★★ ()

There are no updated packages for RHEL/CentOS yet.

Ой вэй!

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

открывая исходники, разработчик в том числе говорит: «Ребзя, мне нечего скрывать! Я ничего против вас не замышляю!»

Именно. Открытые исходники - это еще не защита от атак. Это защита от того, кто берется вас защищать, но не говорит, как.

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

bleeding-edge

21 месяц назад

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

full_inu ()

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

Зоопаркам привалило посетителей...

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

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

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