LINUX.ORG.RU

Выявлена дыра, позволяющая «уронить» компьютер с Linux под любым пользователем

 ,


0

2

В списке рассылки разработчиков ядра Linux (LKML) был обнародован код, позволяющий через вызов функции ядра socketpair() создать процесс, съедающий 100% процессорного времени и все файловые дескрипторы. Процесс, будучи запущенным от имени любого пользователя, может привести систему к состоянию полной неработоспособности.

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

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

★★★★★

Проверено: post-factum ()
Последнее исправление: post-factum (всего исправлений: 2)

Ответ на: комментарий от amorpher

Патч не устраняет проблему:

Hmm... it seems its another problem, chains are very long so we hit a NMI watchdog.

I guess we should limit to a very small number, like 64, or rewrite the garbage collector to a better algo.

http://lkml.org/lkml/2010/11/25/43

MaratIK
()

Говорит же вам Шишкин про алгоритмы и про МГИМО. Не хотите слушать - жрите, жрите это linux-way говно.

Патч для устранения данной проблемы уже опубликован.


Опубликован, но не работает: «Hmm... it seems its another problem, chains are very long so we hit a NMI watchdog. I guess we should limit to a very small number, like 64, or rewrite the garbage collector to a better algo.»

Manhunt ★★★★★
()

А вот и конец жизненного пути linux :)

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

> А ulimit -n не спасает?

Simple kernel attack using socketpair. easy, 100% reproductiblle, works under guest. no way to protect :(

See source attached.

Process become in state 'Running' but not killalble via kill -KILL.

eat 100% CPU, eat all available internal file descriptors in kernel :(

Manhunt ★★★★★
()

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

Вот одна (от которой патч): http://lkml.org/lkml/2010/11/23/395

Вот вторая (без патча): http://lkml.org/lkml/2010/11/25/8 и http://www.spinics.net/lists/netdev/msg147904.html

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

> пустые циклы тоже сжирают 100 ресурсов, только никто еще не догадался патч написать.

пустые циклы можно убить через -KILL

MaratIK
()

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

Сразу есть захотелось. Так аппетитно написано! Пойду на кухню.

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


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

Fischer
()

Надеюсь это немного отрезвит горячего финского парня. Как говорится горькая правда иногда лучше чем сладкая ложь. А то у него синдром имени товарища Сталина - «головокружение от успехов»

Tester ★★★
()

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

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

Кстати да. Надо мной уже виндузятники смеются. В Линухе дыр говорят больше чем в семерке. Да еще таких, которые забодают на ровном месте.

Помню какую-то книгу читал... Хакеры ядра... Лучшие из лучших...

valich ★★★
()

>Пробный патч, который, тем не менее, не устраняет проблему

Тонкий психологический ход, что бы сильно нервы не трепать.

alcoholic
()

Не удивлюсь если Линус прибежит к старику Столману со словами: «Отец, прости засранца! Давай пилить gnu/mach! :'(»

anonymous
()

попробовал, поработало, потормозило систему, сдохло само, ниче не упало. чяднт

$ uname -a

Linux arch 2.6.36-ARCH #1 SMP PREEMPT Sun Oct 31 07:51:30 UTC 2010 i686 Intel(R) Celeron(R) CPU 2.53GHz GenuineIntel GNU/Linux

anonymous
()

внезапно. Ждем еб^W патчей.

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

Говорил я где-то в толксах про модульную архитектуру ядра...

А можно исходники глянуть?

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

>Не знаю кто как, а я не запускаю непроверенный код на своей машине.

категорически плюсую!
З.Ы. дырка забавная.

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

> Говорит же вам Шишкин про алгоритмы и про МГИМО. Не хотите слушать - жрите, жрите это linux-way говно.

Д'Артаньян, перестаньте нести чушь. Проблема с unkillable-процессами - родимое пятно Unix, и давно известна. Никаких особых знаний алгоритмов здесь не требуется.

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

Тоже запустил, пробовал убить сделать ренайс, не помогло. Само не сдохло. Разумеется, тормозит сильно, но в консоли можно спокойно работать.Пришлось делать ребут. Но ничего не поломалось после этого.

uname -a Linux mydoom 2.6.35-23-generic #40-Ubuntu SMP Wed Nov 17 22:14:33 UTC 2010 x86_64 GNU/Linux

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

> Программа по ссылке успешно грохает не только Linux, но и FreeBSD 8.1. Kernel panic :(

Забыл сказать, что пришлось заменить SOCK_SEQPACKET на SOCK_DGRAM

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

> Никаких особых знаний алгоритмов здесь не требуется.

Там сборка мусора в ядре облажалась. И даже если запускать ее раньше, чем закончатся ресурсы, ей нужно слишком много времени. Потому что писало её безграмотное быдло, которое считает, что «особых знаний алгоритмов не требуется».

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

Вот сейчас yaourt -Suy запустил, ядро обновилось, может, пофиксили?

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

>Потому что писало её безграмотное быдло, которое считает, что «особых знаний алгоритмов не требуется».

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

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

Ну так напишите лучше. Чего здесь-то кричите? Кому вы свою крутость показываете? Тому же выдлу, которого здесь ower 90 %?

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