The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Удалённо эксплуатируемая уязвимость в Glibc, охватывающая большинство сетевых приложений в Linux

16.02.2016 20:13

Исследователи безопасности из компаний Google и Red Hat выявили опасную уязвимость (СVE-2015-7547) в системной библиотеке Glibc. Уязвимость проявляется при вызове приложениями функции getaddrinfo() и может привести к выполнению кода в системе в случае возврата DNS-сервером специально оформленного ответа, который может быть сформирован злоумышленником в результате MITM-атаки, при получении контроля над DNS-сервером, отвечающим за отдачу запрошенной DNS-зоны, или при обращении к домену, за обработку которого отвечает DNS-сервер атакующих. Таким образом, для совершения успешной атаки злоумышленникам достаточно подтолкнуть пользователя обратиться к подконтрольному им доменному имени из любой программы, в которой применяется вызов getaddrinfo().

Проблема вызвана переполнением буфера в NSS-модуле nss_dns, которое присутствует в обработчиках запросов как по UDP (send_dg), так и по TCP (send_vc). Уязвимость проявляется при вызове функции getaddrinfo в режимах AF_UNSPEC или AF_INET6, использование которых приводит к одновременной отправке двух запросов для получения данных для типов записей A (IPv4) и AAAA (IPv6). Суть проблемы в том, что буфер для сохранения результата создаётся ненадлежащего размера и хвост ответа записывается в область стека за пределом буфера (в буфер 2048 может придти до 65535 байт данных). Для демонстрации уязвимости подготовлен рабочий прототип эксплоита.

Проблема присутствует с мая 2008 года, начиная с выпуска glibc 2.9. Инженеры Google обратили внимание на уязвимость столкнувшись с повторяющимся крахом клиента SSH при попытке обращения к одному из хостов. В процессе разбора уязвимости инженеры Google с удивлением обнаружили, что информация об уязвимости уже сообщалась разработчикам Glibc людьми столкнувшимися с похожими проблемами и находится в системе отслеживания ошибок Glibc с 13 июля 2015 года. Написав о проблеме сопровождающим Glibc, исследователи узнали, что два сотрудника Red Hat тоже обратили внимание на данную ошибку и занимаются её анализом.

Исправление пока доступно в виде патча. Обновления с устранением уязвимости пока выпущены только для RHEL 6/7 и Debian (eglibc, glibc). Оценить появление обновлений в других дистрибутивах можно на следующих страницах: Ubuntu, Fedora,openSUSE, SLES, Slackware, Gentoo, CentOS. В качестве обходных мер защиты рекомендуется ограничить на межсетевом экране максимальный размер DNS-ответов значением в 512 байт для UDP и 1024 байт для TCP.

  1. Главная ссылка к новости (http://openwall.com/lists/oss-...)
  2. OpenNews: Состоялся релиз системной библиотеки Glibc 2.22
  3. OpenNews: Уязвимость GHOST в Glibc может проявляться в web-приложениях на языке PHP
  4. OpenNews: Критическая уязвимость в Glibc, которая может привести к удалённому выполнению кода в Linux
  5. OpenNews: Представлена стандартная Си-библиотека Musl 1.0.0, развиваемая в качестве альтернативы Glibc
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/43886-glibc
Ключевые слова: glibc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 20:42, 16/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Согласно https://sourceware.org/bugzilla/show_bug.cgi?id=18665 проблема была зарепорчена 2015-07-13. Более полугода понадобилось чтобы понять что имеют дело с уязвимостью.
     
  • 1.2, Аноним (-), 20:44, 16/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Для дебиана уже есть libc* amd64 2.19-18+deb8u3 с закрытием этой уязвимости.

    Ну и мне кажется, что, например, для веерной атаки не нужно ломать никакие серверы и встраваться посередине. Достаточно поиметь свой домен usefulsoftishere.to, на сервер зоны поставить DNS-ответчик, формирующий нужный ответ, и на форумах разместить ссылочку на http://usefulsoftishere.to

     
     
  • 2.3, Аноним (-), 20:46, 16/02/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Отвечу сам себе. Можно даже все проще сделать: любой почтовик постоянно чего-нибудь ресолвит.
     

  • 1.4, Нимано (?), 21:28, 16/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Уязвимость проявляется при вызове функции

    С нетерпением жду комментариев от клоуна! Ведь всего то нужно отключить локальный ресолвер типа анбаунд, ASLR и не забыть про W^X -- и все, ваша не-форточка опять уязвимое, дырявое шерето!!1 ))  

     
     
  • 2.96, rico (ok), 14:21, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    митрофаныч, ты чтоль?
     
     
  • 3.97, Andrey Mitrofanov (?), 16:18, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > митрофаныч, ты чтоль?

    Нет, не я.

     

  • 1.5, Аноним (-), 21:49, 16/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –19 +/
    А как же тысячи глаз которые смотрят в GPL код ?
     
     
  • 2.7, Аноним (-), 22:07, 16/02/2016 [^] [^^] [^^^] [ответить]  
  • –18 +/
    То, что open source inherently more secure than proprietary software - миф.

    // b.

     
     
  • 3.12, Музыкант (ok), 22:47, 16/02/2016 [^] [^^] [^^^] [ответить]  
  • +20 +/
    Лучше пожизенно страдать от простых хакеров и постоянно залатывать дыры, через которые они лезут, чем пожизненно быть эксплуатируемым корпорациями и не догадываться о том, почему весь мир катится в жопу.
     
     
  • 4.28, Аноним (-), 08:54, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >чем пожизненно быть эксплуатируемым корпорациями

    Инженеры Google и сотрудники RedHat согласны с твоим утверждением.

     
  • 4.64, freeman2 (ok), 07:01, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все верно, но мир катится в жопу вне зависимости от того открыт код glibc или нет.
     
     
  • 5.85, gogo (?), 04:29, 21/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Скорость разная
     
     
  • 6.94, count0krsk (ok), 12:48, 27/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В разных точках Континуума ))
    А тем временем у меня носок прохудился. Так что дырка в либЦ подождёт ))
     
  • 2.10, РОСКОМУЗОР (?), 22:29, 16/02/2016 [^] [^^] [^^^] [ответить]  
  • +24 +/
    Вот и увидели. А в твоей винде не увидят и через 100500 лет.
     
     
  • 3.19, Аноним (-), 01:12, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А смотреть есть на что: место бага - функция длинной в 432 строчки, которая принимает на вход 16 аргументов, с кучей goto и простынями if-else.
     
  • 3.63, Аноним (-), 06:41, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А в твоей винде не увидят и через 100500 лет.

    Там все совсем по-другому. Не пользователи следят за кодом, а код следит за пользователями. И их, похоже, это устраивает. :)

     
     
  • 4.95, count0krsk (ok), 12:50, 27/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Там все совсем по-другому. Не пользователи следят за кодом, а код следит
    > за пользователями. И их, похоже, это устраивает. :)

    Их просто насилуют. А мнение жертвы мало кого интересует )) Если конечно это не публичный БДСМ, и жертва должна, лижа ботинки Хозяина, благодарить его. Но до этого Микрософт пока не довел своих рабов.

     

  • 1.8, Аноним (-), 22:10, 16/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    RHEL5 не подвержен
     
     
  • 2.21, Аноним (-), 01:52, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    "Зачем тебе CentOS 5?", - говорили они. "Шестой супестабилен", - говорили они. "Ты никогда не прикрутишь этот демон к старм либам", - смеялись они надо мной. В итоге поиметы их серверы, а мой - нет.
     
     
  • 3.43, Stax (ok), 14:27, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Насчет демона и либов это правда, однако. Запустим демон в контейнере с новыми либами - и он будет уязвим, даже если на хосте 5-ка. Уязвимости в glibc они такие..
     
  • 3.57, vvvv (??), 20:32, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > "Зачем тебе CentOS 5?", - говорили они. "Шестой супестабилен", - говорили они.
    > "Ты никогда не прикрутишь этот демон к старм либам", - смеялись
    > они надо мной. В итоге поиметы их серверы, а мой -
    > нет.

    Зачем тебе 6-ой? Уже давно везде 7-ку ставлю.

     
  • 3.87, Аноним (-), 16:42, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > "Зачем тебе CentOS 5?", - говорили они. "Шестой супестабилен", - говорили они.
    > "Ты никогда не прикрутишь этот демон к старм либам", - смеялись
    > они надо мной. В итоге поиметы их серверы, а мой -
    > нет.

    Твой локалхост и так вне опасности - кому он нафиг сдался-то?

     

  • 1.9, не дую (?), 22:15, 16/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Тысячи глаз АНБшников смотрят код, зевая уныло засыпая на клаве и в монике крутится жесткая парнуха.

    Это я утрирую конечно, но думаю что и "тысячи глаз" тоже утрирование.

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

     
     
  • 2.14, Аноним (-), 23:49, 16/02/2016 [^] [^^] [^^^] [ответить]  
  • –10 +/
    да тут не раз говорили что главное достоинство это тысячи глаз которые смотрят код :)
    Оказывается это миф и экслойт явно ходит на черном рынке уже давно..
     
     
  • 3.59, Аноним (-), 05:24, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ...эксплойт явно ходит на черном рынке уже давно...

    Dnssec и dnscrypt-proxy спасут тебя, о неведомый страдалец!
     
     
  • 4.62, Аноним (-), 06:15, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    P.S. Естественно при условии, что предполагается использование заслуживающих доверие днс-серверов.
     
  • 3.66, Адекват (ok), 08:09, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > да тут не раз говорили что главное достоинство это тысячи глаз которые
    > смотрят код :)
    > Оказывается это миф и экслойт явно ходит на черном рынке уже давно..

    Гляди сколько тебе минусов понаставили, не понравилось лягушкам, что в их болото камнем кинул, у лягушек забомбило и болото пошло пузырями.
    Тоже об этом думал, с учетом того, что резолв днс-имени может идти с привилегиями рута ( если рут пинганет хост по имени к примеру) - перспективы открываются просто шикарные.
    Интересно сколько еще дырок есть в линуксе, которые можно удаленно эксплуатировать, которые скорее всего эксплатируются эксплоитами, которые есть на черном рынке.
    Может это последня дырка, ну вот прям ваще ? А то сначла heardbleed, потом shellshock, теперь вот это :)


     
     
  • 4.67, Аноним (-), 08:55, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В целом согласен, только две поправки:локального получения рута - предыдущей известной баги - ни у кого нигде не замечено ну и пинг, как и весь icmp, выполняется только от рута. суид-бит и тп.
     
     
  • 5.73, Аноним (-), 10:50, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не поверишь 50% процентов пропорционально строкам кода... просто на черном рынке как ты говоришь много заказчиков на эту уязвимость вот ее и слили..
     
  • 4.68, Аноним (-), 09:18, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Давай не будем заниматься гадательной демагогией. Где "истории успеха", типа: "я пропинговал вот этот хост, получил переполнение, все пропало, все упало, памагите"!
    Имя хоста давай, буду пинговать.
     
     
  • 5.70, Адекват (ok), 09:30, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > вот этот хост, получил переполнение, все пропало, все упало, памагите"!

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


     
     
  • 6.71, Аноним (-), 09:44, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Про рута тебе (?) уже вчера все разжевали подробно, почитай еще раз, если не понял.
     
     
  • 7.72, Аноним (-), 09:46, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    P.S. Если не согласен - практическую реализацию уязвимости с полной выкладкой в студию.
     

  • 1.11, ttwo (?), 22:41, 16/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или я ошибаюсь?
     
     
  • 2.13, й (?), 23:49, 16/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    да, верно, по умолчанию делает
     
     
  • 3.88, Аноним (-), 16:44, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > да, верно, по умолчанию делает

    Интеллигентные люди это перво-наперво отключают. И вот почему. Когда у тебя половина инфраструктуры валяется, в частности, пара корпоративных DNS, а тебе удаленно зайти не получается просто потому что SSH долбится к лежащим DNS и надо тащить жoпу через полгорода чтобы глянуть на консоль.... дошло или повторить?

     
     
  • 4.93, Michael Shigorin (ok), 21:50, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Интеллигентные люди это перво-наперво отключают. И вот почему. Когда у тебя половина
    > инфраструктуры валяется, в частности, пара корпоративных DNS, а тебе удаленно зайти
    > не получается просто потому что SSH долбится к лежащим DNS и
    > надо тащить жoпу через полгорода чтобы глянуть на консоль....
    > дошло или повторить?

    В оракле такая /dev/arse с DNS?  Да, с UseDNS no в таком случае комфортнее, но описанный DoS на альте в подобных ситуациях не наблюдал -- задержка получалась то ли 30, то ли 60 секунд, не помню уже даже.

     
  • 2.15, ALex_hha (ok), 23:50, 16/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
    > я ошибаюсь?

    В CentOS 6/Ubuntu 14 по дефолту включенно

     
  • 2.22, EHLO (?), 02:11, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
    > я ошибаюсь?

    Да, и?

    >для типов записей A (IPv4) и AAAA (IPv6)

     

     
     
  • 3.23, Аноним (-), 06:21, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    строчки о том что прямое и обратное не совпадают не видел ?
     
     
  • 4.48, й (?), 15:33, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    да и обратный резолв --- это ровно такое же a/aaaa
     
     
  • 5.52, й (?), 16:01, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ой, не, ptr же. но т.к. вызывается и прямой тоже, это не так важно.
     
     
  • 6.54, EHLO (?), 17:06, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > ой, не, ptr же. но т.к. вызывается и прямой тоже, это не
    > так важно.

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

     
  • 2.82, Аноним (-), 23:32, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
    > я ошибаюсь?

    Делал. В последних версиях для UseDNS поменяли значение по умолчанию на «No».

     
     
  • 3.83, ttwo (?), 15:01, 20/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> А ведь openssh сервер, при соединении обратные ресолвы делает (по умолчанию). Или
    >> я ошибаюсь?
    > Делал. В последних версиях для UseDNS поменяли значение по умолчанию на «No».

    На мой взгляд правильно. А кому надо другое поведение поправит конфигурацию.

     

  • 1.16, Mirraz (ok), 00:20, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Если в качестве локального резолвера у меня работает dnsmasq, можно спать спокойно?
     
     
  • 2.17, anonymous (??), 00:33, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Сам то dnsmasq не из астрала ответы берёт.
     
  • 2.18, anonymous (??), 00:34, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Если в качестве локального резолвера у меня работает dnsmasq, можно спать спокойно?

    Нет, проблема в libc, если твой локальный резолвер не фильтрует каким-либо образом эксплуатирующие уязвимость DNS-ответы - тебе он ничем не поможет

     

  • 1.20, Аноним (-), 01:50, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В SLES прилетело: https://www.suse.com/support/update/announcement/2016/suse-su-20160472-1.html
     
     
  • 2.41, SysA (?), 13:20, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В SLES прилетело: https://www.suse.com/support/update/announcement/2016/suse-su-20160472-1.html

    В Gentoo тоже уже есть sys-libs/glibc-2.22-r2:2.2 с патчем.

     

  • 1.24, Адекват (ok), 07:06, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    dnssec решит проблему ?
     
     
  • 2.49, й (?), 15:34, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > dnssec решит проблему ?

    не. контроля над днс-зоной (хоть прямой, хоть обратной) -- достаточно, чтобы запихнуть туда запись больше двух килобайт. dnssec не спасёт.

     
     
  • 3.60, Аноним (-), 05:55, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > контроля над днс-зоной

    Как бы не совсем простое условие - получить контроль за более-менее обширной зоной.

     
     
  • 4.84, й (?), 19:54, 20/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    зачем обширной? достаточно той, которую будет кто-то резолвить (от авторезолва в ssh и до картинки в интернете).
     

  • 1.30, бедный буратино (ok), 09:28, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    glibc - это только linux? серверы на openbsd от этого не болеют?
     
     
  • 2.36, Аноним (-), 11:21, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Предвосхищая следующий вопрос: Angband тоже вне зоны риска, спи спокойно.
     
  • 2.65, freeman2 (ok), 07:08, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    del
     

  • 1.31, Нанобот (ok), 09:33, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >рекомендуется ограничить на межсетевом экране максимальный размер DNS-ответов значением в 512 байт для UDP и 1024 байт для TCP

    А почему не 2048? (переполнение же возникает после 2к)

     
  • 1.34, Адекват (ok), 10:41, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Я так понял мой коммент приняли за троллинг, и по этому удалили, да ? ну не беда, давайте БЕЗ троллинга.

    Я вот понял так, что уязвимость эксплуатируется с правами ядра (а если нет, то с какими) ? Если с правами ядра, то можно послать такой шелл-код, который не только выполнит зловредный код, но и заметет за собой все следы - это конечно не совсем простая задача, но реализуемая.
    Кроме того, если "с правами ядра", то в данный момент у вас могут модифицированные бинари и либы в вашей системе, которые не будут показывать активность зловреда в вашей системе, но сам зловред там будет, всякие там ps, netstat, tcpdump, просто не будут показывать активность зловредного бинаря.
    "Проблема вызвана переполнением буфера" - известна давно, но никто из "афторов" программ, что используются в линуксе не почесался перепроверить свой код на наличие этой проблемы.
    Отношение чисто формальное к своей работе, но людей можно понять - написать программу, и "написать программу и сопровождать ее" - две разные вещи. а кому охота больше _работать_ за одни и те же деньги :) ?
    Что характерно - если бы эту дырку не нашли (а нашли ее чисто случайно) - ее бы могли эксплуатировать в тихую еще добрый десяток лет :)

     
     
  • 2.35, тоже Аноним (ok), 10:49, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь попробуйте без троллинга и без высеров.
     
  • 2.37, sage (??), 11:31, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Шелл-код выполняется от имени приложения, которое резолвит домен.
     
     
  • 3.81, тот самый парень (?), 19:48, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    но не в случае пинга.
     
  • 2.39, Аноним (-), 13:00, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    И давно у нас за резольвинг ДНС ядро отвечать начало?
     
     
  • 3.89, Аноним (-), 16:46, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И давно у нас за резольвинг ДНС ядро отвечать начало?

    Тормоз, оно всегда и отвечало. И у вас и у нас.

     
  • 2.47, Нимано (?), 15:09, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Я вот понял так, что уязвимость эксплуатируется с правами ядра (а если
    > нет, то с какими) ?

    Нет.

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

    Ага, а еще можно в  холодильнике на луну или на марс слетать – переделать холодильник  задачка не совсем тривиальная, но реализуемая!

    > Что характерно - если бы эту дырку не нашли (а нашли ее
    > чисто случайно) - ее бы могли эксплуатировать в тихую еще добрый
    > десяток лет :)

    https://en.wikipedia.org/wiki/Address_space_layout_randomization
    > 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 флагом в руках и барабаном на шее ...

     

  • 1.40, Аноним (-), 13:12, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Более обидно вот это:
    "Проблема присутствует с мая 2008 года, начиная с выпуска glibc 2.9."
    Это ж вообще жуть получается...
     
     
  • 2.90, Аноним (-), 16:47, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Более обидно вот это:
    > "Проблема присутствует с мая 2008 года, начиная с выпуска glibc 2.9."
    > Это ж вообще жуть получается...

    Угу, дальше следует перл про то, как тысячи глаз бороздят просторы Большого Театра.....

    PS. Как страшно жить.

     
     
  • 3.92, Michael Shigorin (ok), 21:48, 26/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Угу, дальше следует перл про то, как тысячи глаз бороздят просторы Большого

    оракла.

     

  • 1.42, f1ex (ok), 13:47, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    пишет что
    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

    должно помочь. Так ли это ?

     
     
  • 2.51, й (?), 15:40, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    ох, поломает оно вам zone transfer'ы. лучше обновитесь.
     

  • 1.45, Аноним (-), 14:42, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    так а если просто поставить в настройках гугловские dns?
     
     
  • 2.50, й (?), 15:38, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > так а если просто поставить в настройках гугловские dns?

    а толку с того, если гугль днс всё равно ходит к сторонним dns-серверам, которые могут выдавать такие ответы?

     
     
  • 3.61, Аноним (-), 06:11, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > гугль днс всё равно ходит к сторонним dns-серверам

    Будем надеяться, что не совсем к каким попало, тем более, что иженеры Гугла давно об этой проблеме осведомлены. А проблемы типа MITM вполне решаемы. Хотя, малый риск, конечно, есть и здесь, абсолютно все не проконтролируешь.

    > так а если просто поставить в настройках гугловские dns?

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

     
     
  • 4.98, Аноним (-), 13:32, 19/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > иженеры Гугла давно об этой проблеме осведомлены

    А, ну раз осведомлены, значит и проблемы нет!!

    Забыл спросить. А они после того как стали осведомленными начали модифицировать DNS-трафик или они осведомлены и на этом всё?

     

  • 1.55, Kodir (ok), 17:31, 17/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Да есть уже давно патч, причём сразу для всей системы: s/C++/D/g !
    Уже просто стыдно в 21 веке читать "переполнение буфера" - будто линукс на перфокартах пишут!
     
     
  • 2.56, аноним2 (?), 20:32, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    у вас Д в головном мозге
     
  • 2.58, Andrey Mitrofanov (?), 21:28, 17/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да есть уже давно патч, причём сразу для всей системы: s/C++/D/g !

    Libc на D уже переписали? :D   А смысл?!

     
     
  • 3.69, Аноним (-), 09:23, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    беспокоит ещё где уважаемый 'кодир' плюсы увидал, что он менять собрался-то.
     

  • 1.74, evkogan (?), 16:36, 18/02/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В OPenSuse до сих пор нет.
    Я конечно понимаю, что это не Ent, но не до такой же степени
     
     
  • 2.75, zeppelin (?), 17:00, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Есть. (http://lists.opensuse.org/opensuse-security-announce/2016-02/msg00041.html)

    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)

     
     
  • 3.76, evkogan (?), 18:04, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В списке есть, а в доступных к закачке rpm нет.
    http://download.opensuse.org/update/13.2/
     
  • 3.77, Аноним (-), 18:35, 18/02/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Только для версии 42.1, 13.2 и 13.1 никто, похоже, обновлять не собирается.
     
     
  • 4.78, evkogan (?), 09:14, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Только для версии 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)"

    Т.е. еще год патчи должны быть.

     
  • 2.79, evkogan (?), 09:19, 19/02/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Поправка сейчас еще раз проверил обновления, наконец доехало. OpenSuse 13.2

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру