LINUX.ORG.RU
Новости — Безопасность  

В ядрах Linux серии 2.6 обнаружена локальная root-уязвимость

 ,


0

0

Практически во всех ядрах Linux ветки 2.6 месяц назад была обнаружена уязвимость, позволяющая любому приложению, имеющему доступ к X-серверу (то есть любому графическому приложению) путём переполнения памяти через механизм MIT-SHM и создания особого сегмента памяти, получающего root-привилегии. Это уязвимость именно ядра: X и его уязвимости использованы не были. Решением является либо обновление до ядра версии 2.6.32.19, 2.6.34.4, 2.6.35.2, либо правкой /etc/X11/xorg.conf и заданием там опции 

   Section "Extensions"
      Option "MIT-SHM" "disable"
   EndSection

Стоит отметить, что Red Hat также обновил и исправил своё ядро в RHEL.

Баг в багзилле Red Hat

Коммит, устраняющий проблему

Описание атаки (PDF)

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

★★★★★

Проверено: isden ()

 ← 1 2 3 4 5 6 →
Ответ на: комментарий от Siado

>Найденную уязвимость быстро исправляют, в отличие от всякой пропиетарщины, где она годами лежит

ключевое слово здесь *найденную*. а ненайденных (неизвестных разработчикам) много и там, и тут

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

и да, это преимущество не GPL, а публичности исходников

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

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

Это если уязвимость находится анализом исходников, данная уязвимость найдена с обратной стороны - при работе программы, как и в случае vmsplice, которая висела аж полгода, кстати

frame ★★★
()

Ммде, коммит в традициях ведрописателей линукса: функция check_stack_guard_page не только чекает стек (как можно было предположить из названия) но еще и увеличивает его (долбаная неожиданность). И не кидайтесь в меня ссаными тряпками, для меня Линукс - лучшая ОС, хоть и не без недостатков.

A-234 ★★★★★
()

А гугл замену Х писал вроде бы, когда Х выкинут то?

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

>ага, для каждой архитектуры — свое ядро. круто.
а то - прикинь насколько багов будет больше и насколько они будут разнообразнее ^_^

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

Марш-марш. При чём. Без X-сервера не сделаешь ничего.

Без доступа к системе тоже. Страшный баг в клавиатуре с монитором, ага? Или в OpenSSH?

Deleted
()

sh-3.2# uname -srm Linux 2.6.18-194.11.1.el5.centos.plus i686

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

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

px ★★★
()

Та там еще не вспаханное поле этих уязвимостей, просто никому оно не надо. Находят так, случайно типа, ойй смотри опять дырка. =)

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

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

wintrolls ☆☆
() 
# ps uax | grep Xorg
root      1378  1.9  4.4  70936 45956 tty1     Ss+  Jul29 584:07 /usr/bin/Xorg

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

Censo ★
()

Кошмар. Нет пути.

anonymous
()

As Marcus Meissner from the SUSE security team explained to heise Security, SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel. SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability.

http://www.h-online.com/open/news/item/Root-privileges-through-Linux-kernel-b...

выводы делайте сами

HighwayStar ★★★★★
()

Поздравляю!

От всей души поздравляю с открытой и замурованной багой в ядре Linux. Столько лет пользователи сидели на пороховой бочке, никто и не чесался.

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

если не ССЗБ, то в Linux не будет такого феерического расплодника заразы как на винде.

Подсказка: левые репозитории БИНАРНЫХ пакетов + небольшая социальная инженерия. ;)

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

Писать большими буквами что это ПЛОХО и НЕ НУЖНО. А тех, кто делает свои репы и не добавляет свой софт в репы дистров называть ПЛОХИМИ (Skype, Chrome в Убунте)

vertexua ★★★★★
()
Ответ на: комментарий от ls-h

>А если X завернуть в SELinux/AppArmor, то атакующий сможет только уронить графическую сессию.

Сказок не надо ;-) Selinux/AppArmor тут дело 10е :) ибо есть возможность выполнять код в контексте ядра. Поздравляю Linux с нахождением баги которая была 6 лет в ядре (то есть начиная с 2.6.0 и скорее всего во всех 2.4). Ура товарищи! :)

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

> Опера — это одна большая уязвимость. У нее даже логотип в виде дырки.

Ну так и на логотипе в твоей аватарке кривое окошко куда как меньше дыры, которую оно безуспешно пытается прикрыть. ;)

another ★★★★★
()

Переходите на SUSE

И SELinux не спасает, хорошо хоть в свое время на Сусю перешел. Novel заботится о безопасности, потому что это серьёзная компания с большим штатом и солидной историей, настоящие профессионалы, а не то что всякие там RedHat и Canonical - гики и нищеброды.

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

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

Для сборки мусора из-за арифметики указателей придётся усложнить проверку ипользуемости памяти (простой поиск значений может привести к освобождению участка памяти, на серидину которого есть указатель)

Использование арифметики указателей не делает ни одну из указанных тобой проблем принципиально нерешаемой.

anonymous
()
Ответ на: Поздравляю! от iZEN

Во бзде они тоже есть, только кому придет в голову их искать?

Nakgidveef
()

В убунте пофиксили уже.

amorpher ★★★★★
()

прочитал, pacman -Syu, а вы тут всё собираете-разбираете :)

pechastyle
()

Похоже что добавление этих опций в xorg.conf решает ещё и проблему i830waitlpring. Задрало на работе уже а раз! и сразу стало ОК.

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

>> Использование арифметики указателей не делает ни одну из указанных тобой проблем принципиально нерешаемой.

кажный раз проверять на уровне kernel-space ?

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

Ты читал, на что я ответил?

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

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

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

>Интернет надо читать, подключив витую пару в моск. Вот это Ъ!

Главное шоб было куда подключить (:

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

> Для предотвращения переполнения буфера нужна проверка на выход за границы того самого буфера, что можно осуществить и при арифметике указателей.

Можно, конечно.

Использование арифметики указателей не делает ни одну из указанных тобой проблем принципиально нерешаемой.

Разумеется. Но есть человеческий фактор. Так сам программист вычисляет адрес элемента массива, проверяет на выход за границы массива и т.д., а так это за него делает компилятор.

Nxx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 →
Безопасность