Исследователи безопасности из компаний Google и Red Hat выявили (https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html) опасную уязвимость (СVE-2015-7547 (https://security-tracker.debian.org/tracker/CVE-2015-7547)) в системной библиотеке Glibc. Уязвимость проявляется (https://googleonlinesecurity.blogspot.ru/2016/02/cve-2015-75...) при вызове функции getaddrinfo() и может привести к выполнению кода в системе в случае возврата DNS-сервером специально оформленного ответа, который может быть сформирован злоумышленником в результате MITM-атаки или при получении контроля над DNS-сервером, отвечающим за отдачу запрошенной обратной зоны.Проблема вызвана переполнением буфера в NSS-модуле nss_dns, которое присутствует в обработчиках запросов как по UDP (send_dg), так и по TCP (send_vc). Уязвимость проявляется при вызове функции getaddrinfo в режимах AF_UNSPEC или AF_INET6 (в ряде случаев), использование которых приводит к одновременной отправке двух запросов для получения данных для типов записей A (IPv4) и AAAA (IPv6). Суть проблемы в том, что буфер для сохранения результата создаётся ненадлежащего размера и хвост ответа записывается в область стека за пределом буфера. Для демонстрации уязвимости подготовлен (https://github.com/fjserna/CVE-2015-7547) рабочий прототип эксплоита.
Исправление пока доступно в виде патча. Обновления с устранением уязвимости пока выпущены только для Debian (eglibc (https://lists.debian.org/debian-security-announce/2016/msg00...), glibc (https://lists.debian.org/debian-security-announce/2016/msg00...)). Оценить появление обновлений в других дистрибутивах можно на следующих страницах: RHEL 6 (https://rhn.redhat.com/errata/rhel-server-6-errata.html), RHEL 7 (https://rhn.redhat.com/errata/rhel-server-7-errata.html), Ubuntu (http://www.ubuntu.com/usn/), Fedora (https://admin.fedoraproject.org/updates/),openSUSE (http://lists.opensuse.org/opensuse-security-announce/), SLES (https://www.suse.com/support/update/), Slackware (http://www.slackware.com/security/list.php?l=slackware-secur...), Gentoo (http://www.gentoo.org/security/en/index.xml), CentOS (http://lists.centos.org/pipermail/centos-announce/).
URL: http://openwall.com/lists/oss-security/2016/02/16/3
Новость: http://www.opennet.me/opennews/art.shtml?num=43886
Согласно https://sourceware.org/bugzilla/show_bug.cgi?id=18665 проблема была зарепорчена 2015-07-13. Более полугода понадобилось чтобы понять что имеют дело с уязвимостью.
Для дебиана уже есть libc* amd64 2.19-18+deb8u3 с закрытием этой уязвимости.Ну и мне кажется, что, например, для веерной атаки не нужно ломать никакие серверы и встраваться посередине. Достаточно поиметь свой домен usefulsoftishere.to, на сервер зоны поставить DNS-ответчик, формирующий нужный ответ, и на форумах разместить ссылочку на http://usefulsoftishere.to
Отвечу сам себе. Можно даже все проще сделать: любой почтовик постоянно чего-нибудь ресолвит.
> Уязвимость проявляется при вызове функцииС нетерпением жду комментариев от клоуна! Ведь всего то нужно отключить локальный ресолвер типа анбаунд, ASLR и не забыть про W^X -- и все, ваша не-форточка опять уязвимое, дырявое шерето!!1 ))
митрофаныч, ты чтоль?
> митрофаныч, ты чтоль?Нет, не я.
А как же тысячи глаз которые смотрят в GPL код ?
То, что open source inherently more secure than proprietary software - миф.// b.
Лучше пожизенно страдать от простых хакеров и постоянно залатывать дыры, через которые они лезут, чем пожизненно быть эксплуатируемым корпорациями и не догадываться о том, почему весь мир катится в жопу.
>чем пожизненно быть эксплуатируемым корпорациямиИнженеры Google и сотрудники RedHat согласны с твоим утверждением.
Все верно, но мир катится в жопу вне зависимости от того открыт код glibc или нет.
Скорость разная
В разных точках Континуума ))
А тем временем у меня носок прохудился. Так что дырка в либЦ подождёт ))
Вот и увидели. А в твоей винде не увидят и через 100500 лет.
А смотреть есть на что: место бага - функция длинной в 432 строчки, которая принимает на вход 16 аргументов, с кучей goto и простынями if-else.
> А в твоей винде не увидят и через 100500 лет.Там все совсем по-другому. Не пользователи следят за кодом, а код следит за пользователями. И их, похоже, это устраивает. :)
> Там все совсем по-другому. Не пользователи следят за кодом, а код следит
> за пользователями. И их, похоже, это устраивает. :)Их просто насилуют. А мнение жертвы мало кого интересует )) Если конечно это не публичный БДСМ, и жертва должна, лижа ботинки Хозяина, благодарить его. Но до этого Микрософт пока не довел своих рабов.
RHEL5 не подвержен
"Зачем тебе CentOS 5?", - говорили они. "Шестой супестабилен", - говорили они. "Ты никогда не прикрутишь этот демон к старм либам", - смеялись они надо мной. В итоге поиметы их серверы, а мой - нет.
Насчет демона и либов это правда, однако. Запустим демон в контейнере с новыми либами - и он будет уязвим, даже если на хосте 5-ка. Уязвимости в glibc они такие..
> "Зачем тебе CentOS 5?", - говорили они. "Шестой супестабилен", - говорили они.
> "Ты никогда не прикрутишь этот демон к старм либам", - смеялись
> они надо мной. В итоге поиметы их серверы, а мой -
> нет.Зачем тебе 6-ой? Уже давно везде 7-ку ставлю.
> "Зачем тебе CentOS 5?", - говорили они. "Шестой супестабилен", - говорили они.
> "Ты никогда не прикрутишь этот демон к старм либам", - смеялись
> они надо мной. В итоге поиметы их серверы, а мой -
> нет.Твой локалхост и так вне опасности - кому он нафиг сдался-то?
Тысячи глаз АНБшников смотрят код, зевая уныло засыпая на клаве и в монике крутится жесткая парнуха.Это я утрирую конечно, но думаю что и "тысячи глаз" тоже утрирование.
Смотреть то смотрят и даже бабки за это получают заинтересованные лица. Но добросовестно ли они отрабатывают бабки, вот в чем вопрос.
да тут не раз говорили что главное достоинство это тысячи глаз которые смотрят код :)
Оказывается это миф и экслойт явно ходит на черном рынке уже давно..
...эксплойт явно ходит на черном рынке уже давно...
Dnssec и dnscrypt-proxy спасут тебя, о неведомый страдалец!
P.S. Естественно при условии, что предполагается использование заслуживающих доверие днс-серверов.
> да тут не раз говорили что главное достоинство это тысячи глаз которые
> смотрят код :)
> Оказывается это миф и экслойт явно ходит на черном рынке уже давно..Гляди сколько тебе минусов понаставили, не понравилось лягушкам, что в их болото камнем кинул, у лягушек забомбило и болото пошло пузырями.
Тоже об этом думал, с учетом того, что резолв днс-имени может идти с привилегиями рута ( если рут пинганет хост по имени к примеру) - перспективы открываются просто шикарные.
Интересно сколько еще дырок есть в линуксе, которые можно удаленно эксплуатировать, которые скорее всего эксплатируются эксплоитами, которые есть на черном рынке.
Может это последня дырка, ну вот прям ваще ? А то сначла heardbleed, потом shellshock, теперь вот это :)
В целом согласен, только две поправки:локального получения рута - предыдущей известной баги - ни у кого нигде не замечено ну и пинг, как и весь icmp, выполняется только от рута. суид-бит и тп.
Ты не поверишь 50% процентов пропорционально строкам кода... просто на черном рынке как ты говоришь много заказчиков на эту уязвимость вот ее и слили..
Давай не будем заниматься гадательной демагогией. Где "истории успеха", типа: "я пропинговал вот этот хост, получил переполнение, все пропало, все упало, памагите"!
Имя хоста давай, буду пинговать.
> вот этот хост, получил переполнение, все пропало, все упало, памагите"!В том то вся и фишка, юный падаван, что не "все упало", а "теперь контроль над вашей системой получили злоумышленники".
Вот как вы можете определить, что сейчас на вашем сервере не находятся посторонние (при условии что у них есть рут) ?
Про рута тебе (?) уже вчера все разжевали подробно, почитай еще раз, если не понял.
P.S. Если не согласен - практическую реализацию уязвимости с полной выкладкой в студию.
А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или я ошибаюсь?
да, верно, по умолчанию делает
> да, верно, по умолчанию делаетИнтеллигентные люди это перво-наперво отключают. И вот почему. Когда у тебя половина инфраструктуры валяется, в частности, пара корпоративных DNS, а тебе удаленно зайти не получается просто потому что SSH долбится к лежащим DNS и надо тащить жoпу через полгорода чтобы глянуть на консоль.... дошло или повторить?
> Интеллигентные люди это перво-наперво отключают. И вот почему. Когда у тебя половина
> инфраструктуры валяется, в частности, пара корпоративных DNS, а тебе удаленно зайти
> не получается просто потому что SSH долбится к лежащим DNS и
> надо тащить жoпу через полгорода чтобы глянуть на консоль....
> дошло или повторить?В оракле такая /dev/arse с DNS? Да, с UseDNS no в таком случае комфортнее, но описанный DoS на альте в подобных ситуациях не наблюдал -- задержка получалась то ли 30, то ли 60 секунд, не помню уже даже.
> А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
> я ошибаюсь?В CentOS 6/Ubuntu 14 по дефолту включенно
> А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
> я ошибаюсь?Да, и?
>для типов записей A (IPv4) и AAAA (IPv6)
строчки о том что прямое и обратное не совпадают не видел ?
да и обратный резолв --- это ровно такое же a/aaaa
ой, не, ptr же. но т.к. вызывается и прямой тоже, это не так важно.
> ой, не, ptr же. но т.к. вызывается и прямой тоже, это не
> так важно.Дане, он чисто для журнала обратный делает в любой не экзотической конфигурации. Можно потрэйсить или tcpdump посмотреть.
Ман читал, там неправда.
> А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
> я ошибаюсь?Делал. В последних версиях для UseDNS поменяли значение по умолчанию на «No».
>> А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
>> я ошибаюсь?
> Делал. В последних версиях для UseDNS поменяли значение по умолчанию на «No».На мой взгляд правильно. А кому надо другое поведение поправит конфигурацию.
Если в качестве локального резолвера у меня работает dnsmasq, можно спать спокойно?
Сам то dnsmasq не из астрала ответы берёт.
> Если в качестве локального резолвера у меня работает dnsmasq, можно спать спокойно?Нет, проблема в libc, если твой локальный резолвер не фильтрует каким-либо образом эксплуатирующие уязвимость DNS-ответы - тебе он ничем не поможет
В SLES прилетело: https://www.suse.com/support/update/announcement/2016/suse-s...
> В SLES прилетело: https://www.suse.com/support/update/announcement/2016/suse-s...В Gentoo тоже уже есть sys-libs/glibc-2.22-r2:2.2 с патчем.
dnssec решит проблему ?
> dnssec решит проблему ?не. контроля над днс-зоной (хоть прямой, хоть обратной) -- достаточно, чтобы запихнуть туда запись больше двух килобайт. dnssec не спасёт.
> контроля над днс-зонойКак бы не совсем простое условие - получить контроль за более-менее обширной зоной.
зачем обширной? достаточно той, которую будет кто-то резолвить (от авторезолва в ssh и до картинки в интернете).
glibc - это только linux? серверы на openbsd от этого не болеют?
Предвосхищая следующий вопрос: Angband тоже вне зоны риска, спи спокойно.
del
>рекомендуется ограничить на межсетевом экране максимальный размер DNS-ответов значением в 512 байт для UDP и 1024 байт для TCPА почему не 2048? (переполнение же возникает после 2к)
Я так понял мой коммент приняли за троллинг, и по этому удалили, да ? ну не беда, давайте БЕЗ троллинга.Я вот понял так, что уязвимость эксплуатируется с правами ядра (а если нет, то с какими) ? Если с правами ядра, то можно послать такой шелл-код, который не только выполнит зловредный код, но и заметет за собой все следы - это конечно не совсем простая задача, но реализуемая.
Кроме того, если "с правами ядра", то в данный момент у вас могут модифицированные бинари и либы в вашей системе, которые не будут показывать активность зловреда в вашей системе, но сам зловред там будет, всякие там ps, netstat, tcpdump, просто не будут показывать активность зловредного бинаря.
"Проблема вызвана переполнением буфера" - известна давно, но никто из "афторов" программ, что используются в линуксе не почесался перепроверить свой код на наличие этой проблемы.
Отношение чисто формальное к своей работе, но людей можно понять - написать программу, и "написать программу и сопровождать ее" - две разные вещи. а кому охота больше _работать_ за одни и те же деньги :) ?
Что характерно - если бы эту дырку не нашли (а нашли ее чисто случайно) - ее бы могли эксплуатировать в тихую еще добрый десяток лет :)
А теперь попробуйте без троллинга и без высеров.
Шелл-код выполняется от имени приложения, которое резолвит домен.
но не в случае пинга.
И давно у нас за резольвинг ДНС ядро отвечать начало?
> И давно у нас за резольвинг ДНС ядро отвечать начало?Тормоз, оно всегда и отвечало. И у вас и у нас.
> Я вот понял так, что уязвимость эксплуатируется с правами ядра (а если
> нет, то с какими) ?Нет.
> то можно
> послать такой шелл-код, который не только выполнит зловредный код, но и
> заметет за собой все следы - это конечно не совсем простая
> задача, но реализуемая.Ага, а еще можно в холодильнике на луну или на марс слетать – переделать холодильник задачка не совсем тривиальная, но реализуемая!
> Что характерно - если бы эту дырку не нашли (а нашли ее
> чисто случайно) - ее бы могли эксплуатировать в тихую еще добрый
> десяток лет :)https://en.wikipedia.org/wiki/Address_space_layout_randomiza...
> The Linux PaX project first coined the term "ASLR", and published the first design and implementation of ASLR in July 2001.https://pax.grsecurity.net/docs/pax.txt
https://pax.grsecurity.net/docs/noexec.txt
> PaX makes the stack and the heap (all anonymous mappings in general) non-executable.а пока:
./paxtest blackhat
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
...
Anonymous mapping randomization test : 30 quality bits (guessed)
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (PIE) : 30 quality bits (guessed)
...
удачи "проэксплуатировать" хоть в тихую, хоть c флагом в руках и барабаном на шее ...
Более обидно вот это:
"Проблема присутствует с мая 2008 года, начиная с выпуска glibc 2.9."
Это ж вообще жуть получается...
> Более обидно вот это:
> "Проблема присутствует с мая 2008 года, начиная с выпуска glibc 2.9."
> Это ж вообще жуть получается...Угу, дальше следует перл про то, как тысячи глаз бороздят просторы Большого Театра.....
PS. Как страшно жить.
> Угу, дальше следует перл про то, как тысячи глаз бороздят просторы Большогооракла.
пишет что
sudo iptables -I INPUT -p udp --sport 53 -m state --state ESTABLISHED -m length --length 2048: -j DROP
sudo iptables -I INPUT -p tcp --sport 53 -m state --state ESTABLISHED -m length --length 2048: -j DROP
sudo ip6tables -I INPUT -p udp --sport 53 -m state --state ESTABLISHED -m length --length 2048: -j DROP
sudo ip6tables -I INPUT -p tcp --sport 53 -m state --state ESTABLISHED -m length --length 2048: -j DROPдолжно помочь. Так ли это ?
ох, поломает оно вам zone transfer'ы. лучше обновитесь.
так а если просто поставить в настройках гугловские dns?
> так а если просто поставить в настройках гугловские dns?а толку с того, если гугль днс всё равно ходит к сторонним dns-серверам, которые могут выдавать такие ответы?
> гугль днс всё равно ходит к сторонним dns-серверамБудем надеяться, что не совсем к каким попало, тем более, что иженеры Гугла давно об этой проблеме осведомлены. А проблемы типа MITM вполне решаемы. Хотя, малый риск, конечно, есть и здесь, абсолютно все не проконтролируешь.
> так а если просто поставить в настройках гугловские dns?
Тут еще проблема в том (по крайней мере, для домашних локалхостов), что российские провайдеры взяли моду перенаправлять запросы к сторонним днс-серверам на свои. А что там в их провайдерской кухне дальше делается, х.з.
> иженеры Гугла давно об этой проблеме осведомленыА, ну раз осведомлены, значит и проблемы нет!!
Забыл спросить. А они после того как стали осведомленными начали модифицировать DNS-трафик или они осведомлены и на этом всё?
Да есть уже давно патч, причём сразу для всей системы: s/C++/D/g !
Уже просто стыдно в 21 веке читать "переполнение буфера" - будто линукс на перфокартах пишут!
у вас Д в головном мозге
> Да есть уже давно патч, причём сразу для всей системы: s/C++/D/g !Libc на D уже переписали? :D А смысл?!
беспокоит ещё где уважаемый 'кодир' плюсы увидал, что он менять собрался-то.
В OPenSuse до сих пор нет.
Я конечно понимаю, что это не Ent, но не до такой же степени
Есть. (http://lists.opensuse.org/opensuse-security-announce/2016-02...)This update for glibc fixes the following security issues:
- CVE-2015-7547: A stack-based buffer overflow in getaddrinfo allowed
remote attackers to cause a crash or execute arbitrary code via crafted
and timed DNS responses (bsc#961721)
В списке есть, а в доступных к закачке rpm нет.
http://download.opensuse.org/update/13.2/
Только для версии 42.1, 13.2 и 13.1 никто, похоже, обновлять не собирается.
> Только для версии 42.1, 13.2 и 13.1 никто, похоже, обновлять не собирается.Хамство у них на официальном сайте
"The following distributions are expected to receive updates until the specified date:
openSUSE 13.2 - EXPECTED First Quarter of 2017 (2 months after release of Leap 42.2)
Leap 42.1 - EXPECTED Second Quarter of 2017 (6 months after 42.2)"Т.е. еще год патчи должны быть.
Поправка сейчас еще раз проверил обновления, наконец доехало. OpenSuse 13.2