LINUX.ORG.RU
Новости — Debian  

А ларчик открывался просто.


0

0

А тем временем, пока все прогрессивное человечество отмечает первый день зимы и скорое приближение рождественских праздников, бравые парни из Red Hat и Suse kernel и security teams наконец-то разобрались в хитром экслойте, повергшим в ужас мировую общественность кощунственным взломом нескольких серверов проекта Debian. Все оказалось проще, нехороший человек воспользовался уязвимостью integer overflow в в системном вызове brk ядра Linux версий до 2.4.23, приводящей к доступу из пользовательской программы к kernel address space. Что любопытно, еще в сентябре Эндрю Мортон (Andrew Morton) указал на эту ошибку, но исправления были отложены до выхода новой версии ядра.

P.S. Любопытно то, что для Debian пакеты с исправлениями для были доступны и ранее, но apt-get update оказалось непосильной командой для администраторов, отвественных за безопасность проекта. Подробности по ссылке.

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

★★

Проверено: ivlad

 ← 1 2 →

Поясните кто-нить плз, существует ли что-нибудь типа kernel security team, как происходит процесс разработки ядра? Когда у нас выступал Дэвид Лебланк, лидер microsoft security strategies team, то он сказал очень умную вещь (имхо с намеком на open source) "It doesn't matter how many people look at a piece of code, it reaaly matters how many people exactly know what are they looking at."

poliakov ★
()

пока Debian не взломали об ошибке никто не знал кроме разработчиков ядра, а вы говорите, что только M$ скрывает информацию о дырах

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

> "It doesn't matter how many people look at a piece of code, it reaaly matters how many people exactly know what are they looking at."

уууу... психоделическая фраза, а по сути - глупость сморозил

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

С чего бы это? По-моему, очень правильная вещь. 100 ламеров, которые имеют исходники ядра и 'проверят' их, выдав заключение, что все ок не заменят одного специалиста, который знаком со всеми тонкостями, и которого действительно заботит безопасность, а не погоня за быстрым и некачественным результатом

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

>пока Debian не взломали об ошибке никто не знал кроме разработчиков ядра, а вы говорите, что только M$ скрывает информацию о дырах

Тебе кто-то мешает подписаться на список рассылки Kernel Security Team?

А M$ столь же свободно распространяет информацию об уязвимостях в своих продуктах?

Ikonta_521 ★
()

Linux надежнее чем Windows

Получается, что основные проблемы с безопасностью Linux

каксаются серверов? А на десктопе Linux является лучшим

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

эксплойты, как правило, локальные. И если у меня на десктопе

не запущен ни один сервис, беспокоится не о чем (разве что

iptables-rules настроить). Уважаемые специалисты Linux,

поправьте, если ошибся.

anonymous
()
Ответ на: Linux надежнее чем Windows от anonymous

Любой unix host обязан быть безопасным.

Есть такая пословица

"Привыкнешь дома пердеть и в церкви не удержишься"

С таким подходом тебя когда нибудь поймают.

Sun-ch ☆
()
Ответ на: комментарий от poliakov

> "It doesn't matter how many people look at a piece of code, it reaaly matters how many people exactly know what are they looking at."

Хорошая фраза. Сама по себе. Только пустая (читай трепотня). Типа "красота спасет мир" и типа того. Все знают, что спасет, но когда и от кого - х.з. Очень в стиле микровсоса. Сказать, что у их специалистов самые длинные пиписьки слабо (засмеют ведь), но брякнуть что-то такое неопределенное, чтобы вы сами додумали - это с радостью.

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

То же самое, см. выше.

anonymous
()

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

anonymous
()

патч есть?

anonymous
() 

Вот кстати сами патчи от RedHat'а:

- Add TASK_SIZE check to do_brk()
--- linux-2.4.20/mm/mmap.c~     2003-12-01 15:12:20.000000000 +0000
+++ linux-2.4.20/mm/mmap.c      2003-12-01 15:12:42.000000000 +0000
@@ -1059,6 +1059,9 @@
        if (!len)
                return addr;

+       if ((addr + len) > TASK_SIZE || (addr + len) < addr)
+               return -EINVAL;
+
        /*
         * mlock MCL_FUTURE?
         */

- Fix up NPTL local DoS bug (#107942)
--- linux-2.4.20/kernel/fork.c~ 2003-12-01 15:14:35.000000000 +0000
+++ linux-2.4.20/kernel/fork.c  2003-12-01 15:14:57.000000000 +0000
@@ -927,6 +927,7 @@
                if (current->signal->group_exit) {
                        spin_unlock(&current->sighand->siglock);
                        write_unlock_irq(&tasklist_lock);
+                       retval = -EAGAIN;
                        goto bad_fork_cleanup_namespace;
                }
                p->tgid = current->tgid;

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

В ядре Fedora патч - Add TASK_SIZE check to do_brk(), присутствует...

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

Интересно, а какого вообще vm_enough_memory принимает long, а не unsigned long? Маразм какой-то ...

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

> пока Debian не взломали об ошибке никто не знал кроме разработчиков ядра, а вы говорите, что только M$ скрывает информацию о дырах

неправильно. пока Debian не вломали никто не обращал внимания на эту ошибку, которая была пофикшена к тому времени насколкьо я понял...

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

> и что делать 2.4.23 ставить ? > там тоже вроде не все гладко ???

думаю, не стоит брезговать 2.4.23.. Но можно и самому вставить эти три строчки...

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

Так уж и никто?

Paul Starzetz has indenpendently discovered the bug,

Wojciech Purczynski invented and provided numerous

techniques to automatically and efficiently exploit the bug.


Tested and successfully exploited kernel versions include:

o 2.4.20-18.9 as shipped with RedHat 9.0
o 2.4.22 (vanila)
o 2.4.22 with grsecurity patch

Unfortunately we guess that our exploit may have leaked to the

underground.

Усе слили в андерграунд, ну молодцы, че сказать.

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

А разве в sys_brk() нет этой же проблемы? Там присутствуют такие строки :

if (!vm_enough_memory((newbrk-oldbrk) >> PAGE_SHIFT)) goto out; где unsigned long newbrk, oldbrk;

однако vm_enough_memory принимает long.

poliakov ★
()

"но apt-get update оказалось непосильной командой для администраторов" потому что нахрен это все не надо, надо выкладывать готовое, а не обязывать людей для обновления учить кучу нового софта. Такое дерьмо так и будет, пока не будет выложен соответствующий *.tar.gz , к которому все давным давно привыкли.

anonymous
()

запарили одну и ту же новость по 10 раз писать. (Модераторов на мыло ;)

OpenStorm ★★★
()

Так это локальная уязвимость или remote?
Если локальная то как злоумышленник получил shell?
Если удаленная, то пипец всему :(

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

Локальная. Иначе пипец всему уже настал бы. :)

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

Локальная, но очень опасная.

possibility of kernel code and data structures modification as well as

kernel-level (ring0) code execution.

Тут уж ни grsecurity ни RSBAC не спасут?

Sun-ch ☆
()
Ответ на: комментарий от Sun-ch

a у меня 2.4.22 with opemwall path , чтонибудь это значит??

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

не поможет тут RSBAC

possibility of kernel code and data structures modification as well as kernel-level (ring0) code execution.

Т.е. можно менять ACI как угодно... Другое дело, что существующие(й?) exploit'-ы, скорее всего, тупо пытаются что-то запустить с UID 0.

Dselect ★★★
()
Ответ на: комментарий от Sun-ch

дык, потестить то можно... тока эксплоит то где? тока тот который от PoC не предлагать.... ну не хочется сервак перегружать... вдруг не поднимится... а до него пешком минут десять, да еще и по холоду... бррр. неохота.

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

Тогда становится понятно, как был запущен suckit
однако как был получен юзерский акаунт?
Или на Debian.org их раздают на лево и направо?

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

тупой вопрас apt-get поможет , или ядро надо патчить | ставить?

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

>Проверь, а то вот люди пишут

>Tested and successfully exploited kernel versions include: 2.4.22 with grsecurity patch

>Может врут?

Время будет - проверю.

Ибо grsecurity - не единственный вариант. Ветку 2.2 никто не отменял...

Да и чисто из любопытства.

Ikonta_521 ★
()

Забавно...

"Исправление для дистрибутивов ALT Linux Master 2.0, ALT Linux "Утёс-К", ALT Linux Master 2.2 и ALT Linux Junior 2.2 содержится в обновлении от 26 сентября 2003 года"

Видимо, ошибку заметили давно, но не заметили ее серьезности...

Sokrat ★
()
Ответ на: комментарий от Sun-ch

Sun-ch: именно тот.

~~~~~~~~~~~~~~~ mov eax, 1 mov ebx, 0 int 0x80

timespec dd 20,0

filesize equ $ - $$ ~~~~~~~~~~~~~~~

GPF ★
()

Это всё хорошо, но когда они gluck поднимут? Или они ищут оставшиеся эксплойты? "Перечислите все до сих пор не найденые эксплойты в ядре linux и причины, по которым их ещё не залатали"

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

Исправление для дистрибутивов ALT Linux Master 2.0, ALT Linux "Утёс-К",
ALT Linux Master 2.2 и ALT Linux Junior 2.2 содержится в обновлении
от 26 сентября 2003 года:

Я не понял, они 26 пофиксили или сейчас?

Итти на коньяк спорить или не надо?

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

Английским по фону написано - "has been published". Причина захвата серверов была опубликована Debian security team.

Eldhenn ☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
Debian