The OpenNET Project / Index page

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

Новый способ совершения локальной DoS-атаки в Linux и *BSD

25.11.2010 17:02

Найден довольно простой способ совершения локальной DoS-атаки в Linux, основанный на использовании функции socketpair(). Код работает от любого пользователя. Процесс находится в запущенном состоянии, но не "убивается" через SIGKILL (kill -KILL). Поглощает 100% процессора и все доступные файловые дескрипторы в ядре.

Для временного решения проблемы можно использовать grsecurity или применить к ядру патч:



diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index c8df6fd..40df93d 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -259,9 +259,16 @@ static void inc_inflight_move_tail(struct unix_sock *u)
 }

 static bool gc_in_progress = false;
+#define UNIX_INFLIGHT_TRIGGER_GC 2000

 void wait_for_unix_gc(void)
 {
+       /*
+        * If number of inflight sockets is insane,
+        * force a garbage collect right now.
+        */
+       if (unix_tot_inflight > UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress)
+               unix_gc();
        wait_event(unix_gc_wait, gc_in_progress == false);
 } 

Дополнение: с небольшим изменением эксплоит также приводит к зависанию FreeBSD и других BSD-систем.

  1. Главная ссылка к новости (http://lkml.org/lkml/2010/11/2...)
  2. Эксплоит
Автор новости: pavlinux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/28779-linux
Ключевые слова: linux, kernel, dos, attack, security
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (94) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 17:51, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Работает!
     
  • 1.2, gegMOPO4 (ok), 17:54, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что, в ядре и вправду используются конструкции вида gc_in_progress == false?!
     
     
  • 2.3, Зилибоба (ok), 17:58, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для временного решения проблемы можно...
     
     
  • 3.5, JL2001 (ok), 18:07, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Для временного решения проблемы можно...

    судя по отсутствию +сика перед строкой - это строка не во временном патче

     
  • 2.6, Аноним (-), 18:09, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    конечно, и множество других конструкций, в том числе и goto
     
     
  • 3.23, gegMOPO4 (ok), 21:35, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Надеюсь, не в таком (http://thedailywtf.com/Articles/Learning-Something-New.aspx) стиле?
     

  • 1.4, JL2001 (ok), 18:05, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика мусора на мегакрутеньтру языках
     
     
  • 2.7, Аноним (-), 18:11, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика
    > мусора на мегакрутеньтру языках

    Вы путаете язык и программу которая на нём пишется. Разберитесь чем одно от другого отличается.

     
     
  • 3.11, JL2001 (ok), 18:57, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика
    >> мусора на мегакрутеньтру языках
    > Вы путаете язык и программу которая на нём пишется. Разберитесь чем одно
    > от другого отличается.

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

     
     
  • 4.13, anonymous (??), 19:19, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    то есть вы увидели в новости "garbage collector" и стали пороть чепуху.
     
     
  • 5.14, JL2001 (ok), 19:54, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • –12 +/
    > то есть вы увидели в новости "garbage collector" и стали пороть чепуху.

    а может чепуху пороли те кто говорил о ненужности каких либо сборщиков мусора в программах написанных на трусуперкрутьязыках ?

     
     
  • 6.15, anonymous (??), 20:07, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +8 +/
    найденная уязвимость не имеет отношения к отсутсвию сборщика мусора в C. упоминаемая в коде программы "сборка мусора" тоже не имеет к этому отношения. с вашими комментариями проследуйте на лор пожалуйста.
     
  • 4.24, gegMOPO4 (ok), 21:43, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > тоесть программы написанные на сях требуют ручками реализовывать разные гарбаджколлекторы
    > ?

    Как и не на сях. Это совсем другой сборщик, он собирает совсем другой мусор.

     
  • 4.55, тоже Аноним (ok), 12:07, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > тоесть программы написанные на сях требуют ручками реализовывать разные гарбаджколлекторы?

    С какого вдруг "требуют"? Сборщик мусора - технология, которая может быть использована хоть в ассемблере. Вы имеете в виду, что в низкоуровневых языках он не встроен в язык, как в Жабе или ДотНете? Да, не встроен, это общеизвестно. На чем написан сборщик в высокоуровневых языках - вы тоже не в курсе?

    В одном вы правы - Си позволяет реализовать РАЗНЫЕ сборщики. А жабисты и дотнетчики вынуждены пользоваться одним, ОДИНАКОВЫМ ;)

     
  • 2.72, User294 (ok), 15:33, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика
    > мусора на мегакрутеньтру языках

    Ой. Тогда получается что файловые системы с гарбаж коллектром - полное дерьмо? Заметьте, простую файловую систему с GC (например для NOR флеша) можно даже на гольном асме родить. В силу довольно простой логики сбора мусора в такой ФС и прочая.

    Хинт: гарбаж колекторы не являются абсолютным злом сами по себе :). А вот когда их сватают как замену мозга - вот тут да, безмозглые програмеры это зло.

     

  • 1.8, fa (??), 18:11, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Поясните, в чем именно там проблема. Взял пользователь, да и исчерпал ресурс системы. Чем это отличается от for (;;) malloc(100500); ?
     
     
  • 2.9, FractalizeR (ok), 18:13, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Видимо тем, что ваш вариант должен убиваться по SIGKILL. Если успеть послать этот сигнал до того, как ядро его прибьет процесс, исчерпавший память.
     
  • 2.10, Аноним (-), 18:14, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Поясните, в чем именно там проблема. Взял пользователь, да и исчерпал ресурс
    > системы. Чем это отличается от for (;;) malloc(100500); ?

    Тем что процесс можно убить, а тему новости — нет.
    Тем что malloc тратит память польователя, а тема новости — ресурсы ядра.

     

  • 1.12, Zenitur (?), 19:12, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    pavlinux, пропатчил себе я ядро. У меня вопрос: может ли найтись экзотический сот, который с пропатченным ядром откажется работать? Или это исключено?
     
     
  • 2.25, gegMOPO4 (ok), 21:50, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сильно ли просядет производительность, если открыть 2001 сокет?
     
     
  • 3.76, Zenitur (?), 16:04, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Процессор занят на 600%. 6 ядер.
     
  • 2.92, User294 (ok), 01:04, 27/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > может ли найтись экзотический сот,

    Сот? Это что? Сотовик? :)

     

  • 1.16, Аноним (-), 20:15, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    grsecurity не спасает
     
     
  • 2.38, pavlinux (ok), 00:15, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Запрет на создание сокетов юзерами включён?
     
     
  • 3.48, ta (??), 04:16, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    до socket restrictions дело так и не дошло... хватило tpe.
     

  • 1.17, Alexey (??), 20:18, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, а если внутри VPS запустить?
     
     
  • 2.31, Аноним (-), 23:05, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    openvz имеет ограничение на количество unix socket внутри контекста, он спасает от этой атаки.
    linux vserver вроде такого ограничения не имел - так что там эта атака пройдет на ура.
     

  • 1.18, rpisarev (?), 20:55, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://lkml.org/lkml/2010/11/25/43
     
  • 1.19, Аноним (-), 21:13, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    мда, серьёзная штука, машину с четыремя ядрами кладёт через пару секунд в полный даун
     
  • 1.20, Аноним (-), 21:15, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вообще подобного рода вещи, вроде, отправляются в закрытый список, занимающийся безопасностью в ядре
     
     
  • 2.36, pavlinux (ok), 00:11, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не успели, я первый заметил :)
     

  • 1.22, Аноним (-), 21:29, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    че та нынче в линухе баг за багом и очень хорошо, если не рута получают, а просто систему кладут.
     
  • 1.27, Аноним (-), 22:06, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сдается мне что фикс кривой 1 он пытается запускать gc во время любого send, х... большой текст свёрнут, показать
     
     
  • 2.30, Аноним (-), 22:35, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    вот так выглядит более правильно diff --git a include net af_unix h b include ne... большой текст свёрнут, показать
     
     
  • 3.39, pavlinux (ok), 00:29, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    sysctl -w fs.file-max=1000

     
     
  • 4.59, Аноним (-), 13:29, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    и загубишь все на корню - слишком глобальная эта ручка, а если в фиксе заменить за get_max_file() на NR_FILES просто ограничишь очередь сообщений до 8к. и все будет жить.
     
     
  • 5.64, pavlinux (ok), 14:06, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > и загубишь все на корню - слишком глобальная эта ручка, а если
    > в фиксе заменить за get_max_file() на NR_FILES просто ограничишь очередь сообщений
    > до 8к. и все будет жить.

    Не, там синтаксисеская обшибка

    вместо
    fs.files-max, надо
    fs.file-max

     
     
  • 6.70, Аноним (-), 15:30, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ааа. это я полусонным рисовал по памяти.
    спасибо.
     
     
  • 7.71, Аноним (-), 15:32, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > ааа. это я полусонным рисовал по памяти.
    > спасибо.

    просто максимальное количество unix sockets это 2*get_max_files().
    так что ddos тулза упрется в нее в конце концов - но системе станет хреново к тому моменту.
    А потом exit_task -> put file struct - будет оооочень долгим ибо их дохрена.

     
     
  • 8.74, pavlinux (ok), 15:49, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну там дальше идет в ход schedule , по этому при больших file-max, дело до SIG_... текст свёрнут, показать
     
     
  • 9.77, Аноним (-), 16:13, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    exit_task прервать нельзя - в этом code path нету мьютексов - только spinlock ... текст свёрнут, показать
     
     
  • 10.80, pavlinux (ok), 16:25, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    void wait_for_unix_gc void wait_event unix_gc_wait, gc_in_progress ... текст свёрнут, показать
     
     
  • 11.82, Аноним (-), 16:41, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален С теперь козырный вопрос - где вы в exit_task увидели вы... текст свёрнут, показать
     
     
  • 12.87, pavlinux (ok), 18:34, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    так там же for ... текст свёрнут, показать
     
     
  • 13.88, Аноним (-), 18:50, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    позволю себе напомнить код эксплойта int main int fd 2 , ff 2 int t... большой текст свёрнут, показать
     
     
  • 14.90, pavlinux (ok), 19:56, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Чёй-та я не пойму хода Ваших мыслей Схема такая for close 1 124... текст свёрнут, показать
     
     
  • 15.94, Аноним (-), 23:31, 27/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    я там тоже не все понял, но факт в том что in flight реквесты накапливаются на о... текст свёрнут, показать
     
  • 9.89, h4tr3d (ok), 18:52, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    На своём EeePC 1000 при дефолтных сиречь моих рабочих настройках проверил fs ... текст свёрнут, показать
     
  • 2.33, Аноним (-), 23:30, 25/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    вобщем фикс действительно кривой проблема вот в чем 1 мы посылаем сообщение с ... большой текст свёрнут, показать
     

  • 1.32, Buy (??), 23:30, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Запустил, система тут же ушла в даун, даже на другой десктоп не смог переключиться (там был запущен top), минуты через три нажал reset, но комп не смог загрузиться - сработала система защиты на материнке (у меня такое когда-то случалось когда баловался с разгоном проца), потом ящик всёже загрузился с третьей попытки. Прикольно :)
     
     
  • 2.37, pavlinux (ok), 00:14, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Запустил, система тут же ушла в даун, даже на другой десктоп не
    > смог переключиться (там был запущен top), минуты через три нажал reset,
    > но комп не смог загрузиться - сработала система защиты на материнке
    > (у меня такое когда-то случалось когда баловался с разгоном проца), потом
    > ящик всёже загрузился с третьей попытки. Прикольно :)

    Вы эта того, аккуратнее. В новости же написано, что работает!!! :)

     

  • 1.34, тигар (ok), 23:54, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    на самом деле полезная вещь - можно отапливать ЦОДы поставив туда стойки с линакс-машинами.
     
     
  • 2.75, User294 (ok), 15:52, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > на самом деле полезная вещь - можно отапливать ЦОДы поставив туда стойки
    > с линакс-машинами.

    С *BSD такое тоже вполне катит, судя по коментам юзвергов тут и на хабре.

     
     
  • 3.81, Аноним (-), 16:28, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> на самом деле полезная вещь - можно отапливать ЦОДы поставив туда стойки
    >> с линакс-машинами.
    > С *BSD такое тоже вполне катит, судя по коментам юзвергов тут и
    > на хабре.

    Проверил, у меня в FreeBSD 8.1, 7.3 и 6.4 не работает. Видимо комментаторы с хабра от рута тот экспоит запускали.

     

  • 1.40, pavlinux (ok), 00:47, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Прикол, Debian 6.0 в даун не ушёл, только матерился, что "too many open files",
    и удалось корректно выключить через Кнопку "Выйти" на панели.

    Всё, пипец!!! Это окончательный приговор SuSE :)

     
  • 1.41, pavlinux (ok), 02:14, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И ещё apt-get upgrade работает :)

    http://ipicture.ru/uploads/20101126/hSG1NNU3.png

     
     
  • 2.42, Аноним (-), 02:45, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    как выполнить на freebsd?
    что-то не компилится...
     
     
  • 3.43, pavlinux (ok), 03:05, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это уж не сюда.
     
  • 3.51, Аноним (-), 08:33, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > как выполнить на freebsd?
    > что-то не компилится...

    Попробуйте такой вариант: http://lists.freebsd.org/pipermail/freebsd-bugs/2009-February/034227.html

     
  • 3.56, oops (ok), 12:16, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    см. ниже
     
  • 3.63, fidaj (ok), 13:42, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > как выполнить на freebsd?
    > что-то не компилится...

    replace SOCK_SEQPACKET on SOCK_DGRAM

     
  • 2.62, Аноним (-), 13:36, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    шревты!
     

  • 1.44, pavlinux (ok), 03:13, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вобщам дела такие

    # sysctl -w fs.file-max=84000 (где-то от 40000 до 90000)
    Больше 200.000 появляются сильные тормоза, а при 500.000+ можно сказать зависон.
    Приводит к возможности реакций на Ctrl-Alt-Fn, запуска консоли и kill -9
    или  корректного ребута.
    Да, да, на kill -9 оно реагирует, но только минуты через 3 :)

     
  • 1.45, Аноним (-), 03:44, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все линуксовые серваки своему хостеру положил. FreeBSD'шные стоят как ни в чем не бывало.
     
     
  • 2.46, pavlinux (ok), 03:45, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > FreeBSD'шные стоят как ни в чем не бывало.

    "Новый способ совершения локальной DoS-атаки в Linux"

    Где ты слово FreeBSD увидел?


     
     
  • 3.47, Аноним (-), 03:53, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А где я должен был его увидеть? В новости про уязвимость его разумеется нет.
     
     
  • 4.50, Аноним (-), 08:22, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А где я должен был его увидеть? В новости про уязвимость его
    > разумеется нет.

    Капитан, Вы?

     
  • 3.73, User294 (ok), 15:36, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > "Новый способ совершения локальной DoS-атаки в Linux"
    > Где ты слово FreeBSD увидел?

    Наверное где-то в районе http://habrahabr.ru/blogs/linux/108835/ - там народ почему-то утверждает что и некоторые BSD таким манером кладутся (лично не проверял, однако судя по чертыханиям народа - вполне себе работает и на разных *BSD).

     
  • 2.49, Аноним (-), 08:21, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    "сломал крякер своего провайдера, теперь сидит без интернета"
     
  • 2.52, oops (ok), 11:26, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    freebsd тоже подвержена, по крайней мере 8.1 релиз - точно. Только что в ребут ушла
     
     
  • 3.53, oops (ok), 11:36, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    только для BSD надо немного код изменить
    добавить заголовочные файлы

    #include <sys/mount.h>
    #include <sys/wait.h>
    #include <errno.h>
    #include <fcntl.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <unistd.h>

    и заменить все SOCK_SEQPACKET на SOCK_DGRAM.

    8.1-RELEASE без разговоров сразу в ребут =(

     
     
  • 4.54, oops (ok), 11:41, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    тьфу, столько заголовочных написал, не туда посмотрел. Хотя и так работать будет
     
  • 4.69, чупакабра (?), 15:06, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > только для BSD надо немного код изменить

    Без бубна не работает? :)

     
     
  • 5.78, oops (ok), 16:20, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    великий гуру Си?
     
  • 4.83, sacha (?), 17:03, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > #include <sys/mount.h>
    > #include <sys/wait.h>
    > #include <errno.h>
    > #include <fcntl.h>
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <string.h>
    > #include <unistd.h>
    > и заменить все SOCK_SEQPACKET на SOCK_DGRAM.
    > 8.1-RELEASE без разговоров сразу в ребут =(

    Выставил sbsize в 393216 - перестало.

     
     
  • 5.84, Аноним (-), 17:40, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/

    > Выставил sbsize в 393216 - перестало.

    и NFS перестала запускаться, и SSH отвалилось :-(

     
     
  • 6.85, sacha (?), 17:58, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Выставил sbsize в 393216 - перестало.
    > и NFS перестала запускаться, и SSH отвалилось :-(

    У меня ssh не отвалилось.
    nfs нету.
    sbsize не на всех, а только на user-ов, через login.conf
    На моей конфигурации тест отрабатывает 30 раз при таком значении и завершается.

     
     
  • 7.95, pavlinux (ok), 01:13, 28/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Выставил sbsize в 393216 - перестало.
    >> и NFS перестала запускаться, и SSH отвалилось :-(
    > У меня ssh не отвалилось.
    > nfs нету.
    > sbsize не на всех, а только на user-ов, через login.conf
    > На моей конфигурации тест отрабатывает 30 раз при таком значении и завершается.

    Ну вы блин даёте! (с)

     
  • 5.91, Аноним (-), 23:24, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Мне данная мера не помогла. Попробуйте запустить несколько процессов. У меня при sbsize=8M и лимите процессов в 24 тот же кернел паник.
     
  • 5.93, alvarez (?), 03:06, 27/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    У меня FreeBSD 8.1-RELEASE-p1 - уходит в ребут.

    В консоли светится:
    kernel: Cannot dump. Device not defined or unavailable.
    kernel: Automatic reboot in 15 seconds - press a key on the console to abort

    Увеличил maxsockbuf до 393216 по рекомендации sacha (по дефолту - 262144)
    # sysctl -w kern.ipc.maxsockbuf=393216

    Тоже не помогло. Идеи?

     

  • 1.57, прохожий (?), 13:00, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще-то эта проблема была обнаруженна 23-го ноября парнем по имени Vegard Nossum
    (см. http://thread.gmane.org/gmane.linux.kernel/1067149)

    а этот Марк Коренберг (http://lkml.org/lkml/2010/11/25/8) - просто быдлоадмин (см. http://mmarkk.moikrug.ru/), который перепостил код Vegard'а.

    и да, этот трабл - это типичная, известная уже миллион лет fork-бомба (http://en.wikipedia.org/wiki/Fork_bomb).

     
     
  • 2.60, Аноним (-), 13:32, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще-то эта проблема была обнаруженна 23-го ноября парнем по имени Vegard Nossum
    > (см. http://thread.gmane.org/gmane.linux.kernel/1067149)
    > а этот Марк Коренберг (http://lkml.org/lkml/2010/11/25/8) - просто быдлоадмин (см. http://mmarkk.moikrug.ru/),
    > который перепостил код Vegard'а.
    > и да, этот трабл - это типичная, известная уже миллион лет fork-бомба
    > (http://en.wikipedia.org/wiki/Fork_bomb).

    нет. не fork bomb.. а чуть другое. забываем вычитывать с сокета сообщения содержащие внутри ссылку на файловый дисткриптор.

     
     
  • 3.61, Аноним (-), 13:34, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вообще-то эта проблема была обнаруженна 23-го ноября парнем по имени Vegard Nossum
    >> (см. http://thread.gmane.org/gmane.linux.kernel/1067149)
    >> а этот Марк Коренберг (http://lkml.org/lkml/2010/11/25/8) - просто быдлоадмин (см. http://mmarkk.moikrug.ru/),
    >> который перепостил код Vegard'а.
    >> и да, этот трабл - это типичная, известная уже миллион лет fork-бомба
    >> (http://en.wikipedia.org/wiki/Fork_bomb).
    > нет. не fork bomb.. а чуть другое. забываем вычитывать с сокета сообщения
    > содержащие внутри ссылку на файловый дисткриптор.

    ах, да - причем не просто файловые дискрипторы - а _закрытые_ файловые дискрипторы. смысла в которых не больше нуля ибо попытка их задействовать вернет -ENOFILE или что-то такое.

     
  • 2.66, pavlinux (ok), 14:28, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > а этот Марк Коренберг (http://lkml.org/lkml/2010/11/25/8)
    > - просто быдлоадмин (см. http://mmarkk.moikrug.ru/),
    > который перепостил код Vegard'а.

    В оригинале действительно форков напихано, более того, два раза по while (1) {}
    а это быдлоадмин упростил.
      

     
     
  • 3.79, Аноним (-), 16:22, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    в фоках и дело :)
    когда количество таких процессов становится > N_CPU то на exit_task будет уходить время всех процов - и это будет весело, без форка должно нормально жить на 2-4х CPU.
     

  • 1.58, прохожий (?), 13:28, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    по теме - протестил на том что было под руками: трабл подтвердился на Ubuntu 10.10 x86_64 и Debian 5.0.6 x86_64. на RHEL AS 4 U4 x86_64 не прокатило! видимо проблеме подверженны только ванильные ядра.
     
     
  • 2.65, pavlinux (ok), 14:16, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > по теме - протестил на том что было под руками: трабл подтвердился
    > на Ubuntu 10.10 x86_64 и Debian 5.0.6 x86_64. на RHEL AS
    > 4 U4 x86_64 не прокатило! видимо проблеме подвержены только ванильные ядра.

    Сможешь показать из Редхата АС 4
    # sysctl -A | egrep 'gc_|fs.file|inode'

     
     
  • 3.67, прохожий (?), 14:42, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    держи

    $ uname -rm
    2.6.9-78.14.EL x86_64

    $ cat /etc/redhat-release
    Red Hat Enterprise Linux AS release 4 (Nahant Update 4)

    $ sudo /sbin/sysctl -A | egrep 'gc_|fs.file|inode'
    net.ipv6.neigh.eth0.gc_stale_time = 60
    net.ipv6.neigh.lo.gc_stale_time = 60
    net.ipv6.neigh.default.gc_thresh3 = 1024
    net.ipv6.neigh.default.gc_thresh2 = 512
    net.ipv6.neigh.default.gc_thresh1 = 128
    net.ipv6.neigh.default.gc_interval = 30
    net.ipv6.neigh.default.gc_stale_time = 60
    net.ipv6.route.gc_elasticity = 0
    net.ipv6.route.gc_interval = 30
    net.ipv6.route.gc_timeout = 60
    net.ipv6.route.gc_min_interval = 0
    net.ipv6.route.gc_thresh = 1024
    net.ipv4.neigh.eth0.gc_stale_time = 60
    net.ipv4.neigh.lo.gc_stale_time = 60
    net.ipv4.neigh.default.gc_thresh3 = 1024
    net.ipv4.neigh.default.gc_thresh2 = 512
    net.ipv4.neigh.default.gc_thresh1 = 128
    net.ipv4.neigh.default.gc_interval = 30
    net.ipv4.neigh.default.gc_stale_time = 60
    net.ipv4.inet_peer_gc_maxtime = 120
    net.ipv4.inet_peer_gc_mintime = 10
    net.ipv4.route.gc_elasticity = 8
    net.ipv4.route.gc_interval = 60
    net.ipv4.route.gc_timeout = 300
    net.ipv4.route.gc_min_interval = 0
    net.ipv4.route.gc_thresh = 32768
    fs.file-max = 98936
    fs.file-nr = 1812 0 98936
    fs.inode-state = 3222 266 0 0 0 0 0
    fs.inode-nr = 3222 266

     
     
  • 4.68, pavlinux (ok), 14:51, 26/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > fs.file-nr = 1812 0 98936
    > fs.file-max = 98936

    Ну и понятно, с чего бы ей загнуться.

    Хотя скорее дело не в этом. С версии 2.6.9+ много всего поменялось.

     

  • 1.86, Xaionaro (ok), 18:22, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кхм... Почему-то я стал в "мини-новостях" находить интересные новости чаще, чем в главных новостях. :)
     
  • 1.96, pavlinux (ok), 01:18, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати, тут чтоль никого с Microsoft C/C++ нету? :)
     
  • 1.97, cryo (ok), 13:06, 29/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    MacOS 10.6.5 Snow Leopard
    Ядро Darwin 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov  5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 i386

    Запустил эксплойт.

    Система по ощущениям _вообще_ не заметила этого DoS. Все бегает, GUI летает, топ работает :)
    Пишу этот пост.

    Простой kill -15 из-под юзера убил программу моментально.

    Строка из топа:
    7669  a.out        97.9  01:50.11 1/1  0    14   22    104K   240K   320K   9640K  2370M  7669 7592 running  501  175       36      85         42         52992338+ 64

    Нет времени смотреть, как тут реализовано закрытие сокета. Кому интересно - гляньте.

     
     
  • 2.98, fidaj (ok), 13:16, 29/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну теперь кто бы еще и с виндовс машин дал такую же информацию - тогда бы была более полная картина мира :)
    А с мак осью -  забавно...
     

  • 1.99, pavlinux (ok), 23:55, 30/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Свежий патчиг. Для версии 2.6.37-rc4, но думаю руками сами переделаете.




    diff --git a/net/unix/garbage.c b/net/unix/garbage.c
    index c8df6fd..f89f83b 100644
    --- a/net/unix/garbage.c
    +++ b/net/unix/garbage.c
    @@ -96,7 +96,7 @@ static DECLARE_WAIT_QUEUE_HEAD(unix_gc_wait);
    unsigned int unix_tot_inflight;


    -static struct sock *unix_get_socket(struct file *filp)
    +struct sock *unix_get_socket(struct file *filp)
    {
    struct sock *u_sock = NULL;
    struct inode *inode = filp->f_path.dentry->d_inode;
    @@ -259,9 +259,16 @@ static void inc_inflight_move_tail(struct unix_sock *u)
    }

    static bool gc_in_progress = false;
    +#define UNIX_INFLIGHT_TRIGGER_GC 16000

    void wait_for_unix_gc(void)
    {
    + /*
    + * If number of inflight sockets is insane,
    + * force a garbage collect right now.
    + */
    + if (unix_tot_inflight > UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress)
    + unix_gc();
    wait_event(unix_gc_wait, gc_in_progress == false);
    }



     

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



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

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