LINUX.ORG.RU

Linux kernel Ping of Death

 , ,


0

0

В ядре Linux обнаружена уязвимость, позволяющая удаленному злоумышленнику вызвать отказ в обслуживании (зависание ядра), а локальному — получить root-привилегии. Для получения описанного эффекта достаточно отправить на целевой хост серию специально сформированных IPv4-пакетов.

Данной уязвимости подвержены ядра с 2.6.28.10 по 2.6.32-rc8 включительно. В версии 2.6.32 она уже исправлена.

Уязвимость локализована в коде, отвечающем за дефрагментацию IPv4-пакетов (файл net/ipv4/ip_fragment.c, функция ip_frag_reasm), и имеет тип «NULL pointer dereference» (разрешение нулевого указателя). В связи с этим нужно сделать два замечания:

  • Заголовок новости («Ping of Death») носит несколько метафорический характер, так как классические уязвимости Ping of Death, столь популярные в Windows и Unix-системах конца предыдущего столетия, основаны не на разрешении нулевого указателя, а на переполнении буфера при сборке слишком большого фрагментированного пакета. Однако, принцип эксплуатации уязвимости (отправка слишком длинного пакета) и достигаемый эффект (отказ в обслуживании) в обоих случаях одинаковы.
  • Опасность повышения привилегий (получения root-доступа) локальным злоумышленником может быть нейтрализована путем запрещения маппинга кода на нулевой адрес, что достигается установкой в ненулевое значение sysctl-параметра vm.mmap_min_addr (в большинстве современных дистрибутивов он по умолчанию установлен в ненулевое значение, однако после установки wine может быть сброшен в ноль).

Несколько дней назад вышли обновления для Fedora 11, Fedora 12, а также для Ubuntu 9.10. Всем, кто использует уязвимые версии ядра, рекомендуется срочно обновиться.

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

★★★★

Проверено: maxcom ()
Ответ на: комментарий от frame

> потому, что документации/примеров на директикс больше, чем исходников SDL. И SDL это всего лишь обертка над уже существующими API, в т.ч. dinput, dsound. Учим матчасть, вообщем

готовых открытых решений на sdl больше. на одном только python - открываем репозиторий и ищем игры начинающиеся на py - почти все они на pygame

алё, папаша, какой dinput и dsound у меня в linux?

anonymous
()

Запрашивает Миша Рыцаревъ

Интересно, а кто первым это обнаружил- разработчики или хакеры? А насколько больше таких и остальных дыр в windows? (а насколько достоверно про нее то, что на http://www.kvazar.org/showthread.php?t=18891 ). Каково общее количество дыр и недостатков, выявленных и устраненных за всю историю существования линукс-ядра? А сколько невыявленных там еще может таиться? Интересно, а когда наступят времена, когда там недостатков выявлять станет уже нечего?

ua9oas
()
Ответ на: Запрашивает Миша Рыцаревъ от ua9oas

> Интересно, а кто первым это обнаружил- разработчики или хакеры?
Публично - разработчики: http://lkml.org/lkml/2009/11/25/104

А насколько больше таких и остальных дыр в windows?

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

а насколько достоверно про нее то, что на ...

Старая шутка, напечатанная на 1-е апреля в каком-то журнале.

а когда наступят времена, когда там недостатков выявлять станет уже нечего?

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

anonymous
()

Ух! Интерпрайзненько, ping of death то в 2009 году!

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

>готовых открытых решений на sdl больше

чем закрытых на sdl? да :)

открываем репозиторий и ищем игры начинающиеся на py - почти все они на pygame


есть среди них что-то сложнее тетриса, FPS/RTS хотя бы?

алё, папаша, какой dinput и dsound у меня в linux?


алё, дедуля, SDL ещё и ведне работает, и в солярисе. Т.к. является лишь обёрткой для уже существующих API (X11,OpenGL,alsa,GDI,DI,DS и пр.), поскольку ни звуковую, ни графическую, ни систему вводу как таковую ни на одной из поддерживаемых ОС самостоятельно не реализует. Учи матчасть.

frame ★★★
()

Для получения описанного эффекта достаточно отправить на целевой хост серию специально сформированных IPv4-пакетов

А не подскажите какой, а то на локалхосте было бы прикольно проверить :)

anton_jugatsu ★★★★
()

Даа, а мейтейнеры опензюзи до сих пор в анабиозе. Скаким усилием их надо пнуть чтоб они проснулись и начали действовать!? :((

Freiheits-Sender ★★
()
Ответ на: комментарий от tailgunner

> Between 2.6.28.10 and 2.6.29, net/ipv4/ip_fragment.c was patched,

changing from dev_net(dev) to container_of(...). Unfortunately the goto
section (out_fail) on oversized packets inside ip_frag_reasm() didn't
get touched up as well. Oversized IP packets cause a NULL pointer
dereference and immediate hang.

Стесняюсь спросить, а тесты они не запускают перед релизами? Ну, элементарные такие тесты - весь TCP/IP чтобы покрыть, как минимум.

А то как-то странно. Простой протокол, все спецификации в наличии, и тут нате вам.

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

> Стесняюсь спросить, а тесты они не запускают перед релизами? Ну, элементарные такие тесты

Можно увидеть этот «элементарный» тест, на котором этот баг сработает? Что-то вот все никак не могу такой найти.

anonymous
()

LINUX RIP!!!

RIP! BSD FOREVER!!!!

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

> Можно увидеть этот «элементарный» тест, на котором этот баг сработает? Что-то вот все никак не могу такой найти.

Анонимус, тебе объяснить, что такое coverage tests? Ты в net/ipv4/ip_fragment.c посмотрел, перед тем как свой умный коммент написать?

Загляни в функцию ip_frag_reasm, на строчку сразу после метки out_fail:, и разъясни мне, глупому, как coverage test не повалится на этой строчке.

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

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

faustus
()

Вот, а вы говорите в линуксе вирусов нет.

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

Другое дело что этот вирус, о котором пишется, через просмотр сайта разве что повесит систему, ну или сервер ;)

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

> Загляни в функцию ip_frag_reasm, на строчку сразу после метки out_fail:, и разъясни мне, глупому, как coverage test не повалится на этой строчке.

function coverage не повалится

Ты вообще представляешь объем coverage тестов для ядра? Сколько сейчас в ядре строк кода? Сколько строк будут занимать тесты? Сколько времени уйдет на их написание? Сколько дополнительно людей надо, чтобы их поддерживать? Сам напишешь?

И сколько лет займёт прогон таких тестов?

anonymous
()

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

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

> Ты вообще представляешь объем coverage тестов для ядра? Сколько сейчас в ядре строк кода? Сколько строк будут занимать тесты? Сколько времени уйдет на их написание? Сколько дополнительно людей надо, чтобы их поддерживать? Сам напишешь?

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

Во-вторых, имплементация протокола это одно, а всякая шелуха - другое. Имплементация сетевого протокола, как внешне уязвимая часть системы, безусловно должна быть покрыта coverage-тестами от и до. Это азы. Это делает любой разработчик современных сетевых карт. Почему же этого нет в ядре?

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

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

Вопрос не в том, кто это будет делать, а в том, сколько для этого надо ресурсов. Так сколько?

Имплементация сетевого протокола, как внешне уязвимая часть системы, безусловно должна быть покрыта coverage-тестами от и до.

Хорошо, сколько надо ресурсов (людей, времени, строк кода) чтобы «внешне уязвимую часть системы» покрыть тестами «от и до», а также сколько будет занимать один прогон всех этих тестов? И что значит «от и до», какой это тип coverage-тестов?

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

> которые не могут без фотошопа обойтись - так им и надо

За что вы их так? ;)

Я, конечно, фотошопом не пользуюсь. Но вот вчера захотел преобразовать картинку в Gimp к цветовому пространству CIELab и внезапно понял, что Gimp про такое пространство не знает. Ну я то обойдусь, а что прикажете делать людям у которых проекты сделаны в CIELab?

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

> function coverage не повалится Ты вообще представляешь объем coverage тестов для ядра? Сколько сейчас в ядре строк кода? Сколько строк будут занимать тесты? Сколько времени уйдет на их написание? Сколько дополнительно людей надо, чтобы их поддерживать? Сам напишешь? И сколько лет займёт прогон таких тестов?

Необязательно для всего ядра. Хотя бы для ТCP/IP стэка без экзотических протоколов, чтобы хотя бы не валилась удаленно.

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

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

> Хотел бы я посмотреть на тест кода, читающего данные по PCI...

что-то мне сдается, что удаленно задосить систему через баги этого кода очень сложно...

а вообще, даже быдлоподелки на быдлопитоне обвешивают тесткейсами, а ядро — нет. тут на ум приходят разные слова...

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

А не подскажите какой, а то на локалхосте было бы прикольно проверить :)

Увы:

Currently we are not aware of any working exploits. If you feel we are in error or if you are aware of more recent information, please mail us at: vuldb@securityfocus.com.

Интересно, не пробивается ли эксплоит через жестокий файрвол? Хотя, в локалке вряд ли кто захочет мой компьютер хакнуть :)

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

> Потому, что тесты это круто и модно

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

но Си в определенной степени тоже можно отнести к динамически типизированным языкам (!!!) поскольку у него нет отдельно MayBeNullPtr и NotNullPtr. По этому месту мы и видим проблему.

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

> Интересно, а нат контролирует размер проходящих через него фрагментированных пакетов?

в pf это дело режет scrub ж)

val-amart ★★★★★
()
Ответ на: комментарий от k0l0b0k

бояцца?

:)

Просто, тем, кто может, это нафиг не надо.

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

> Хорошо, сколько надо ресурсов (людей, времени, строк кода) чтобы «внешне уязвимую часть системы» покрыть тестами «от и до»

Для TCP/IP, знающий человек, наверное за неделю напишет (включая расширения протокола, типа SACK, CC, и т.д.). Хотя, для TCP/IP эти тесты наверняка где-то есть готовые (если на уровне пакетов, входящих с PHY).

а также сколько будет занимать один прогон всех этих тестов?

Какая разница? Кстати, уверяю: без нагрузочных тестов - немного.

И что значит «от и до», какой это тип coverage-тестов?

Это значит, что каждая строчка кода покрывается во время тестов. Для имплементаций протоколов это очень хорошая проверка, т.к. практически всегда они представляют из себя state machine.

Вообще, что тебя удивляет? Посмотри на тесты в gcc, например.

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

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

написать полностью покрывающие тесты для стэка за неделю - это утопия, говорю как знающий человек

val-amart ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> Необязательно для всего ядра. Хотя бы для ТCP/IP стэка без экзотических протоколов, чтобы хотя бы не валилась удаленно.

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

Вот - человек понимает. Вообще, это еще надо уметь, баги в имплементацию протокола вставлять. Протокол же по сути - доказанный алгоритм, садись и имплементируй по спецификации. Для каждого стейта пару function-level тестиков написал, и все шито-крыто. Но нет, у кернелописателей есть дела поважней.

faustus
()
Ответ на: комментарий от val-amart

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

Если имплементация не какая-то хитрая, то готовые тесты для ротокола (на уровне пакетов входящих с PHY-layer, скажем), и будут покрывать почти все строчки.

написать полностью покрывающие тесты для стэка за неделю - это утопия, говорю как знающий человек

TCP/IP - простой протокол, даже с расширениями. Я тоже, типа, знающий. :3

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

>А если при установке вайна mmap_min_addr не сбросился в ноль — это не фича, а баг

В Gentoo чёрт-те сколько лет wine'ом пользуюсь, но /proc/sys/vm/mmap_min_addr = 4096 :)

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

>а уже вышли 2.6.32.1 и 2.6.31.8 с исправлениями в ext4

А что там исправляли? А то в Gentoo последнее стабильное - 2.6.31-r6 и у меня на нём куча машин с ext4 стоит. Я чего-то упустил? :)

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

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.31.8

ext4: Fix potential fiemap deadlock (mmap_sem vs. i_data_sem)
ext4: Fix insufficient checks in EXT4_IOC_MOVE_EXT
ext4: Wait for proper transaction commit on fsync
ext4: fix incorrect block reservation on quota transfer.
ext4: quota macros cleanup
ext4: ext4_get_reserved_space() must return bytes instead of blocks

...
ext4: Fix memory leak fix when mounting an ext4 filesystem

много там, очень много )

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

> Протокол же по сути - доказанный алгоритм, садись и имплементируй по спецификации.

TCP/IP - простой протокол, даже с расширениями. Я тоже, типа, знающий. :3


ага =) начни с того, что протокола TCP/IP не существует. и закончи тем что почитай хоть один РФЦ и покажи там _алгоритм_.


// вообще-то, я не против тестов, я за, но нельзя же быть таким наивным и поверхностным.

val-amart ★★★★★
()
Ответ на: комментарий от Eddy_Em

> Currently we are not aware of any working exploits. If you feel we are in error or if you are aware of more recent information, please mail us at: vuldb@securityfocus.com.

Логично. Я посмотрел чуток код - похоже, kmalloc должен сказать, что больше нету памяти, но пакет при этом должен быть «хорошим» (меньше 64К). На нормальной системе ядро скорее выкинет собираемый пакет (из-за максимального количества подсоединений, скажем, если флудить фрагментами), чем у нее кончится память.

Т.е., все-таки, не РЕШЕТО, доса/эксплойта нет и не будет.

faustus
()
Ответ на: комментарий от val-amart

> ага =) начни с того, что протокола TCP/IP не существует

Ну да, есть IP и есть TCP, в данном случае речь об IP, кстати, я думал это всем очевидно. Тебе не очевидно?

и закончи тем что почитай хоть один РФЦ и покажи там _алгоритм_

State machine - это алгоритм. Тебе это не очевидно?

вообще-то, я не против тестов, я за, но нельзя же быть таким наивным и поверхностным

Ну ты сходи, почитай RFCs, поимплементируй TCP/IP, потом приходи, высказывай мнение.

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

> Т.е., все-таки, не РЕШЕТО, доса/эксплойта нет и не будет.

Хотя, может, я неправильно код понял - человек вон пишет, что openvas'ом баг обнаружил.

faustus
()

а в debian lenny всё пучком :)

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

Не стоит указывать ..... что тесты это правильно. А то ведь объявят что это все потому что правильная политика партии иметь нестабильный API и развиваться. А ты значит требуешь стабилизации и следовательно враг развития :-)

anonymous
()

Я даже обрадовался что наконец-то реальная уязвимость, да ещё название красивое, а у него в зависимостях vm.mmap_min_addr>0 прописано.
Так и ушёл ни с чем.

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

>Я даже обрадовался что наконец-то реальная уязвимость, да ещё название красивое, а у него в зависимостях vm.mmap_min_addr>0 прописано.

Так и ушёл ни с чем.

А мозгов выставить «0» конечно не хватило? И как для таких пользователей софт писать? А потом плачут, дайте вирь, дайте вирь. Халявщики криворукие.

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

а по существу ответить нечего :) ну что же, деточка, слиф зосчитан

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

>А мозгов выставить «0» конечно не хватило? И как для таких пользователей софт писать? А потом плачут, дайте вирь, дайте вирь. Халявщики криворукие.

Ну да, а чтобы rm -rf /* от простого юзера угрбило всю систему надо от рута сначала chmod -R 777 / сделать. Я говорю что на дефолтной системе (по крайней мере Генте, если для неё можно применить слово «дефолтной») эта х*ня нифига работать не будет и как обычно надо что-то менять/патчить/етц чтобы сплоит (если бы он был) заработал.

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

бггг, конкретных аргументов нет, перешел на личности?

ага =) начни с того, что протокола TCP/IP не существует

Ну да, есть IP и есть TCP, в данном случае речь об IP, кстати, я думал это всем очевидно. Тебе не очевидно?


называть стек TCP/IP протоколом - грубая терминологическая ошибка, простительная только полному дилетанту, которую ты повторяешь систематически.

и закончи тем что почитай хоть один РФЦ и покажи там _алгоритм_

State machine - это алгоритм. Тебе это не очевидно?


еще раз - покажи мне стейт машин для ИП в РФЦ. описание протокола и описание имплементации - две весьма различные и зачастую независимые вещи. Намек на стейт машин в рфц есть только для SCTP и IS-IS, но ты ведь наверное и протоколов-то таких не знаешь.

вообще-то, я не против тестов, я за, но нельзя же быть таким наивным и поверхностным

Ну ты сходи, почитай RFCs, поимплементируй TCP/IP, потом приходи, высказывай мнение.


=)) я автор юзерландовой имплементации базового стека TCP/IP и коммитер в стек OpenBSD, в т.ч. в роутинг и динамическую маршрутизацию. а ты что сделал?

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

> называть стек TCP/IP протоколом - грубая терминологическая ошибка

Бугага. Это назывется «доеб*ться до столба».

я автор юзерландовой имплементации базового стека TCP/IP и коммитер в стек OpenBSD, в т.ч. в роутинг и динамическую маршрутизацию

Ты крут. Расскажи нам о методике, использовавшейся при тестировании твоей реализации _протокола TCP/IP_.

tailgunner ★★★★★
()

Не понял, а вот такое разве от сабжа не спасает? «iptables -A INPUT -f -j DROP»

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