Переполнение буфера в ядрах <2.4.26, 2.6.4

Это уже даже не смешно. Сколько можно? Каждая 20-я новость на ЛОР -
'Уязвимость в ядре Linux'. Такое впечатление что некоторые превратно
поняли идею о продвижении Linux на домашнюю машину и пытаются догнать
Сами Знаете Кого по количеству ошибок

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

AAA! Скажите раз и навсегда, где брать security-патчи для kernel.org (если ядро не из дистра)? Или каждый раз после такой дыры переходить на нестабильную rc-версию?

Зачем? Бери 2.4.26, 2.6.4 или 2.6.5 и ставь. Если ты заметил на этой странице в новости и по ссылке, эти ядра не имеют данной ошибке.

Сколько можно! Ну нету у вменяемого админа юзеров с шеллом! Вернее, есть один - он сам, любимый.

А не проще воспользоваться ядром из дистрибутива?

Сколько можно! Ну нету у вменяемого админа юзеров с шеллом! Вернее, есть один - он сам, любимый.

:)) И админу шелл не нужен-сервер без монитора и клавиатуры. :)))

А вот это уже не радует:

"Paul Starzetz <ihaquer@isec.pl> discovered the vulnerability over half a year ago."

> Сколько можно? Каждая 20-я новость на ЛОР - 'Уязвимость в ядре Linux'. Такое впечатление что некоторые превратно поняли идею о продвижении Linux на домашнюю машину и пытаются догнать Сами Знаете Кого по количеству ошибок

Ну вы как скажете... Эти люди (isec.pl и проч.) просто внимательно, шаг за шагом вычитывают исходники ядра, а особенно - вновь добавляемые патчи. Баги, вылавливаемые таким спобосом - это буквально то, что черпается на дне, после того, как в реальной эксплуатации никто ничего не обнаружил. У микрософта все дыры - это обнаруженное третьими лицами при эксплуатации. Если взять их исходники и анализировать с той же тщательностью, то новость о Windows vulnerability была бы каждой первой.

>Зачем? Бери 2.4.26, 2.6.4 или 2.6.5 и ставь. Если ты заметил на этой странице в новости и по ссылке, эти ядра не имеют данной ошибке.

а не проще одну строчку в код сунуть ;)

> Сколько можно! Ну нету у вменяемого админа юзеров с шеллом!
> Вернее, есть один - он сам, любимый.
>

Хм-ммм... и как же юзеры без шелла работают?

хехе.. помню где-то 2 месяца назад я постил новость про похожую траблу в tcp/ip стеке ядра FreeBSD, а ниже написал что "скорее всего другие ОСи тоже имеют эту траблу" - ой как народ смеялся над FreeBSD и "какая же она дырявая" :)...
Так что линуксу место на десктопе - не дорос он еще до почетного места на боевых серверах.

ЗЫ - думаю через пару недель еще че-нить откопают "такого".

М.

>:)) И админу шелл не нужен-сервер без монитора и клавиатуры. :)))

Ага. И без сети ;)

Дык 2.6.4 неуязвима. А уже 2.6.6rc1 вышло.

Все в порядке у всех давно.

> Бери 2.4.26, 2.6.4 или 2.6.5 и ставь. Если ты заметил на этой
> странице в новости и по ссылке, эти я дра не имеют данной ошибке.

почитай внимательнее оригинал.. как раз 2.4.26 и 2.6.4 и имеют эту ошибку..

>почитай внимательнее оригинал.. как раз 2.4.26 и 2.6.4 и имеют эту ошибку..

This bug has been fixed in the 2.4.26 and 2.6.4 kernel releases. All users of vulnerable kernels are advised to upgrade to the latest kernel version. For further information please contact your vendor.

а ты где читал ?

Synopsis: Linux kernel setsockopt MCAST_MSFILTER integer overflow
Product: Linux kernel
Version: 2.4.22 - 2.4.25, 2.6.1 - 2.6.3

Да даже если последнее В ДАННОМ СЛУЧАЕ уже не имеет ошибки. А если она там есть? Откуда брать security patch всего с парой строчек? (Ну не катит мне ядро из дистра. Долго объяснять почему).

В нормальных дистрах уже давно ядро обновилось

>Ага. И без сети ;)

Дык а что ты хотел?

C2 Security class ;)

Вон в А классе вообще корпуса бетоном заливают ;))

Ну скажите блин не про дистры и не про openwall какой-нибудь, а про общий случай. ГДЕ БРАТЬ SECURITY ПАТЧИ ДЛЯ ЯДРА С KERNEL.ORG, В ТЕХ СЛУЧАЯХ КОГДА НОВОЕ СТАБИЛЬНОЕ ЯДРО С ИСПРАВЛЕНИЯМИ ЕЩЕ НЕ ВЫШЛО? Из рассылки с письмами Линуса что-ли?

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

На мой взгляд две причины которые я выделил являются основными.

>Откуда брать security patch всего с парой строчек?

Сам напиши - где копать носом уже ткнули

вот так, правильно!
Всем ставить новые версии, а то сидят на своих каменных топорах и ничего не замечают!

Да, уронить машину по этой дыре не мудрено.

А вот как гарантированно воспользоваться этим, не уронив систему - не вижу. Ведь то, где выделится кусок с помощью kmalloc зависит от многого.

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

ну что вы все как маленькие накладываешь на ядро openwall или grsecurity и идут лесом все эти buffer overflow

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

Попробуй вставку на асме вставить...;)

http://web.starman.ee/rost/patch2.txt

>http://web.starman.ee/rost/patch2.txt

Это из таких авторитетных источников надо патчи тянуть?

Мда а подпись разработчика (типа kernel.org) где?

На биткипере (http://linux.bkbits.net) я этого патча не нашел, поэтому пришлось выдрать из оффициального patch-2.4.26

И вообще, не хочешь не бери ;) Или сам вырезай, раз такой умный ;)

А нет, всеж-таки нашел,порывшись в source tree ;)

Вот, держите:

http://linux.bkbits.net:8080/linux-2.4/diffs/net/ipv4/ip_sockglue.c@1.11?nav=ind ex.html|src/.|src/net|src/net/ipv4|hist/net/ipv4/ip_sockglue.c

> Сколько можно! Ну нету у вменяемого админа юзеров с шеллом! Вернее, есть один

>- он сам, любимый.

Как же достали идиёты админы, думающие что локальные уязвимости действуют только локально. Поимел я один раз такого админишку через локальную дыру и дырявый php-nuke :) Долго админ извинялся, *опу пальцем затыкал :)

>Эти люди (isec.pl и проч.) просто внимательно, шаг за шагом вычитывают исходники ядра

Ну и че эти суки полгода молчали? Про то что знали только они - это сказки, особенно после обнаружение аналогичного бага в FreeBSD.

Сижу на debian, пользую ядра с kernel.org (несколько лет как). Один товарищ предлагает пользовать сырцы из debian репозитария объясняя это большей заточенностью под дистрибутив. Кто-нибудь может внятно объяснить в чем заключается эта заточенность и что я теряю не используя ее ? Никаких глюков с ядром от kernel.org не наблюдалось и не наблюдается. Ядра меняются регулярно.

Суть в том, что за дырками в ядре следишь не ты, а Debian security team.

А типа Linus не следит ?

Не, он говорит, новые фичи важнее, а секурность мне по барабану.

Типа в Debian ставишь обновление по крону из

deb http://security.debian.org/ woody/updates main contrib non-free

и не занимаешься постоянным отслеживанием новостей с kernel.org и иже с ним.

http://www.debian.org/security/

http://www.debian.org/doc/user-manuals#securing

>ну что вы все как маленькие накладываешь на ядро openwall или grsecurity и идут лесом все эти buffer overflow

Это в ядре то ? ;)

Мля ядро, ядро! Как дети маленькие. Вот как по крупному работать надо! ;))

Обнаружена брешь в TCP, способная привести к концу Интернета Исследователи обнаружили серьезный изъян в технологии, лежащей в основе движения всех информационных потоков в Интернете - TCP (transmission control protocol) - протоколе контроля передачи данных. Это открытие заставило интернет-сообщество принимать срочные меры для поддержания работоспособности всех основных протоколов Всемирной паутины.

Британское правительство объявило о найденной в базовой интернет-технологии уязвимости во вторник, 20 апреля. Эксперты заявили, что обнаруженная брешь позволяет хакерам выводить удаленные компьютеры в оффлайн, а также нарушать работу роутеров - специальных узлов перенаправления потоков данных между разными группами компьютеров, своеобразных связных между разрозненными сетями, входящих в состав Интернета. Успешная атака может перевести роутеры в режим ожидания, и прервать связь во Всемирной паутине на несколько часов.

"Использование этой уязвимости может разрушить своеобразный "клей", который скреплял Интернет воедино", - сказал Роджер Камминг, директор National Infrastructure Security Coordination Centre (NISCC). Пока что, к счастью, не обнаружено атак с использованием бреши в TCP.

"Риск очень значителен. Очень важно вовремя залатать замеченную дыру, пока плохие парни не стали использовать ее для развлечения или перехвата данных", - заявил Пол Викси (Paul Vixie) из Internet Systems Consortium.

Впервые об уязвимости TCP заговорил в прошлом году компьютерный эксперт Пол Уотсон (Paul Watson). Уотсон нашел, что можно прерывать информационные потоки, удаленно вызывая перезагрузку роутера или любого другого компьютера.

Его выводы было поначалу высмеяны экспертами, которые заявили, что подобная атака займет от 4 до 142 лет, поскольку требует подбора постоянно меняющегося номера из 4 миллиардов возможных комбинаций, но Уотсон доказал, что вычислит необходимый номер максимум с 4 попыток, затратив на это всего несколько секунд.

Cisco Systems, известная своими роутерами, стала срочно обновлять программное обеспечение на своей продукции, чтобы защитить пользователей. Корпорация Microsoft заявила, что для пользователей Windows никакой угрозы нет, и компания не собирается принимать никаких экстренных мер. "Будет очень сложно атаковать компьютер под управлением Windows, используя метод Уотсона", - заявил Стив Липнер, директор центра Microsoft по безопасности продуктов.

Оглашение всех результатов исследований Уотсона ожидается в четверг, 22 апреля, на конференции по вопросам сетевой безопасности в Ванкувере (Vancouver). Исследователь предупредил, что хакеры поймут, как именно нужно организовать атаку "спустя буквально пять минут после выхода из зала".

>Вот как по крупному работать надо! ;))

http://www.terrorist.net/ ??? ;)))

--- 1.10/net/ipv4/ip_sockglue.c	Wed Apr 21 03:46:17 2004
+++ 1.11/net/ipv4/ip_sockglue.c	Wed Apr 21 03:46:17 2004
@@ -762,6 +762,8 @@
 		}
 		case MCAST_MSFILTER:
 		{
+			extern int sysctl_optmem_max;
+			extern int sysctl_igmp_max_msf;
 			struct sockaddr_in *psin;
 			struct ip_msfilter *msf = 0;
 			struct group_filter *gsf = 0;
@@ -769,6 +771,10 @@
 
 			if (optlen < GROUP_FILTER_SIZE(0))
 				goto e_inval;
+			if (optlen > sysctl_optmem_max) {
+				err = -ENOBUFS;
+				break;
+			}
 			gsf = (struct group_filter *)kmalloc(optlen,GFP_KERNEL);
 			if (gsf == 0) {
 				err = -ENOBUFS;
@@ -778,7 +784,13 @@
 			if (copy_from_user(gsf, optval, optlen)) {
 				goto mc_msf_out;
 			}
-			if (GROUP_FILTER_SIZE(gsf->gf_numsrc) < optlen) {
+			/* numsrc >= (4G-140)/128 overflow in 32 bits */
+			if (gsf->gf_numsrc >= 0x1ffffff ||
+			    gsf->gf_numsrc > sysctl_igmp_max_msf) {
+				err = -ENOBUFS;
+				goto mc_msf_out;
+			}
+			if (GROUP_FILTER_SIZE(gsf->gf_numsrc) > optlen) {
 				err = EINVAL;
 				goto mc_msf_out;
 			}


вот этот кусок имеет отношение к закрытию дыры или нет :

+			if (optlen > sysctl_optmem_max) {
+				err = -ENOBUFS;
+				break;
+			}


а то влом с 2.4.22 уходить

>Это уже даже не смешно. Сколько можно? >Каждая 20-я новость на ЛОР - >'Уязвимость в ядре Linux'. Такое впечатление что > некоторые превратно поняли идею о продвижении Linux >на домашнюю машину и пытаются догнать >Сами Знаете Кого по количеству ошибок http://www.securitylab.ru/44632.html Глянь ка суда... Вот это всего за неделю... Причем все удаленные. В Линухе только локальные... Которые в винде и уязвимостями то не считают.

А почему бы и нет. :) Вон у ИОСа были проблемы в Циско, так это...не до смеху было всем. ;)

> >ну что вы все как маленькие накладываешь на ядро openwall или grsecurity и идут лесом все эти buffer overflow

> Это в ядре то ? ;)

Будет Oops, но exploit'-ы работать не будут -- неисполняемый стек, однако. Если только не дырка в VM.

видать все не так просто, ибо - $ make bzImage ...... net/network.o: In function `ip_setsockopt': net/network.o(.text+0x1c858): undefined reference to `sysctl_igmp_max_msf' make: *** [vmlinux] Ошибка 1

Ядро 2.4.25 (или 2.4.24 пропатченное до 2.4.25)

p.s. как узнать какие патчи на ядро были наложены?

>p.s. как узнать какие патчи на ядро были наложены?

думаю стоит RH или suse подождать,у них ядра нормальные.

>Будет Oops, но exploit'-ы работать не будут -- неисполняемый стек, однако. Если только не дырка в VM.

Мы это ужо обсуждали и в той штуке от grsecurity дело не в неисполняемом стеке