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

В ядре Linux найдена серьезная уязвимость

 , ,


0

0

В ядрах Linux версии 2.6.x обнаружена уязвимость, которая позволяет локальному пользователю выполнить произвольный код с привилегиями root. Причина проблемы кроется в возможности разыменования NULL-указателя при выполнения определенных действий с пайпами.

Уязвимость уже устранена в ядре версии 2.6.32-rc6, однако обновления пакетов доступно пока лишь пользователям Red Hat Enterprise Linux. Для пользователей других дистрбутивов доступен патч.

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



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

 ← 1 2 3 →

В серьезной уязвимости найдено ядро Linux. 8)

jstm
()

Вот поэтому все прогрессивное человечество использует еще ядра ветки 2.4 не считай 2.6 достаточно стабильным и не боится никаких нулей

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

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

Пропустил, почему? Wine? Я так понял, что некоторые из приложений измненяют этот параметр.

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

>Обновиться и не бояться :)
успокаивай себя, успокаивай...

px ★★★
()

В ветке 2.6.32 устранено 21 октября.

В моём 2.6.27 устранено 24 октября.

Боянисты на ЛОРе - неистребимы (к сожалению)

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

>В ядре линукса найдены подозрительные строчки, похожие на правильный код С.

На аватарке - это ты лопнул, трольчёнок?

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

> опасный вариант будет = 0 , если выше - не страшно
Ну вот зачем людей путаешь? :)
vm.mmap_min_addr от этого эксплойта не спасает,
пруф здесь:
http://lkml.indiana.edu/hypermail/linux/kernel/0907.2/01686.html
---
For instance, if I targeted the 3rd byte in the mmap file_operation
fptr, that would have given me a target userland address of 0x10000.
If I targeted the 4th byte, it would have given me 0x1000000, neither of
which fall under mmap_min_addr protection
---

Капча: "you women" (не вру!!!)

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

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

> проверить легко
> $sysctl vm.mmap_min_addr
> vm.mmap_min_addr = 4096

> опасный вариант будет = 0 , если выше - не страшно

vm.mmap_min_addr = 0x1000; int *p = 0; (*p) - не страшно.
vm.mmap_min_addr = 0x1000; int *p = 0x2000; (*p) - oops!

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

Выходом тут было бы использование разных сегментных дескрипторов для юзерспейса и кернеля, тем более, что всё общение с юзерспейсом всё равно в обязательном порядке через copy_from/to_user делается. Иначе Линус карает анально.

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

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

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

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

nnz вчера час ждал ;)

Меня б спросил :)

function msleep(s:long)
%{
    msleep(THIS->s);
%}

probe kernel.function("pipe_rdwr_open")
{
    msleep(100);
}

Эксплойт на первой итерации же срабатывает.

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

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

Как это там... Сконфигурировать 4G/4G?

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

> К сожалению заюзать можно только локально, либо специально правя конфиги, либо поставив вайн( К сожалению заюзать можно только локально, либо специально правя конфиги, либо поставив виндовс(

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

> Как это там... Сконфигурировать 4G/4G?

Это частный случай, но, в принципе, да: используются два адресных пространства, а не одно плоское.

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

> Выходом тут было бы использование разных сегментных дескрипторов
> для юзерспейса и кернеля
Они и так разные (USER_DS/KERNEL_DS и остальные).
Это ничего не даёт. Защиту на уровне сегментов
можно было бы получить только отказом от flat-модели,
а это уж, извините, неприемлимо в наш век.

anonmyous ★
()

Что странно - эту уязвимость я уже видел.

Она в дистрах обычно недоступна, если, конечно, вы не меняли переменную в sysctl.conf, чтобы правильно работал wine.

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

> Они и так разные (USER_DS/KERNEL_DS и остальные).

Из сисколла юзерские данные видно. На x86 сегментные регистры DS и ES (которые в защищённом режиме играют другую роль) одинаковые, у copy_from/to_user основное копирующее тело одинаковое. Если бы АП были разные, то тела одинаковыми быть бы не могли, потому что rep movs и компания должны ds/es учитывать.

> Это ничего не даёт. Защиту на уровне сегментов
можно было бы получить только отказом от flat-модели,
а это уж, извините, неприемлимо в наш век.

Что неприемлемо? Сегментная модель, как в real-mode? Так речь и не про неё идёт.

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

> У всех стоит либо 4096, либо 65535 (ежели не дебиан, конечно).

Дереференс плохого пойнтера может куда угодно произойти. Обычно пойнтер оказывается обнулён, и mmap_min_addr в таком случае сработает. Но если на месте переменной с пойнтером оказался мусор, то может хоть в середину, хоть в конец адресного пространства разыменоваться. Всю же память не запретишь ммапить :)

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

> На x86 сегментные регистры DS и ES (которые в защищённом режиме
> играют другую роль) одинаковые
Нет, не одинаковые.
Будете спорить?
Посмотрите определения __USER_DS/__KERNEL_DS
в segment_32.h хотя бы...

> Что неприемлемо? Сегментная модель, как в real-mode? Так речь
> и не про неё идёт.
Эх чувак, мне не до шуток...
Когда с объявлениями вышеуказанных констант
разберёшся, отвечу на дальнейшие вопросы.

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

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

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

> в segment_32.h хотя бы...
Там, кстати, табличка есть (прям в хедере), где
весь GDT расписан, так что просто её глянь, и
убедись, что разные дескрипторы.

anonmyous ★
()

Интересно, а все ОС -- такое решето?
И почему все-таки так мало вирусов под GNU/Linux, если так много локал-рут эксплоитов? Далеко не все обновляются ведь и noexec на /home не у всех.

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

> И почему все-таки так мало вирусов под GNU/Linux, если так много
> локал-рут эксплоитов?
По тому, что локал. :) И тут, в отличии от винды,
качать бинарники из файлопомоек не принято - по этому,
для распространения вирей тут нужны только ремот-уязвимости,
коих, пока, к счастью, не так уж и много, и латаются быстро.
Сами пользователи здесь вири не разносят, а вот там - да.

anonmyous ★
()

Если /proc/sys/vm/mmap_min_addr не 0, то возникают проблемы :) с dosemu, ежели кто пользуется :) Это так, к сведению...

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

> Нет, не одинаковые. Будете спорить?

Спорить безполезно, пока не перечитаете мой оригинальный коммент.

Для раздумий, объясните себе, почему на этом скриншоте DS и ES одинаковые: http://www.roberthancock.com/kerneloops.png

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

Вот отсюда http://habrahabr.ru/blogs/linux/74284/#comments

>Скрипт там есть, но он естественно не работает ибо во всех вменяемых дистрах /proc/sys/vm/mmap_min_addr мапится не с нуля

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

>Я правильно понимаю, что если даже mmap_min_addr > 0 и сработает ошибочный код, то будет kernel panic?

>это будет не фатальный panic — таску ядро прибьёт и дальше полетит. разве что инодный мютекс останется залоченным, с ним уже ничего нельзя сделать. так можно выжрать некоторое количество памяти/пидов, устроить дос, но рута так не получить и систему полностью не обрушить.

Так будет рут или нет?

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

> Так будет рут или нет?

Если дереференс произойдёт вникуда, то ничего не будет, кроме kernel oops (или паники, если ядро настроено на панику при oops'е).

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

> Спорить безполезно, пока не перечитаете мой оригинальный коммент.
> Для раздумий, объясните себе, почему на этом скриншоте DS и ES
> одинаковые:
Ну а зачем хитрить? :)
Есть вот этот коммент, тоже ваш:
---
Выходом тут было бы использование разных сегментных дескрипторов для юзерспейса и кернеля
---

А теперь вы говорите, что ES и DS в ядре одинаковые...
А как это к теме относится?
Я вам говорю, что в юзерспейсе и в кернелспейсе
они и так разные, а толку от этого в плане защиты
от данного бага - ноль. К этому есть претензии?
Если нет - ваш коммент был ошибочным.

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

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

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

Кто хитрит-то? Фундаментальная проблема в том, что в сисколле (в кернель-спейсе) видно юзерские данные, к ним можно спокойно обращаться. Я сказал (цитата): "Выходом тут было бы использование разных сегментных дескрипторов для юзерспейса и кернеля, тем более, что всё общение с юзерспейсом всё равно в обязательном порядке через copy_from/to_user делается.". Таким образом, если умолчательно, т.е. через DS, данные юзера не были бы доступны, и к ним нужно было бы обращаться специальным образом через FS или GS, то проблема была бы решена. Заметь, я говорю не про USER_DS и KERNEL_DS.

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

> Фундаментальная проблема в том, что в сисколле (в кернель-спейсе)
> видно юзерские данные, к ним можно спокойно обращаться.
Это не то, чтобы проблема. Это даже хорошо,
а вот что код юзерский можно по ошибке исполнить...

> Я сказал (цитата):
Я это оспорил. Изложите мысль более подробно.

> Таким образом, если умолчательно, т.е. через DS, данные
> юзера не были бы доступны
... то это была бы не flat-модель, и по тому
этого не будет. На сегментной модели давно
поставили крест.

> и к ним нужно было бы обращаться специальным образом через FS или GS
У нас flat-модель, такое невозможно.
Если есть конкретные предложения по
реализации - с интересом послушаю. :)

> Заметь, я говорю не про USER_DS и KERNEL_DS.
Это селекторы, и они разные. Значит и дескрипторы
разные. Ты сказал "если бы были разные", а они
и так такие. Допустим, это была плохая формулировака -
тогда изложи свои мысли по реализации такой защиты,
без отказа от flat model.

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

> этого не будет. На сегментной модели давно
> поставили крест.
Добавлю к этому, что на х86-64
в 64bit long mode она не поддерживается
совсем! Такой расклад вас устраивает в
качестве опровержения ваших идей? :)

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

> Это не то, чтобы проблема. Это даже хорошо,

На самом деле, пофиг, ибо всё взаимодействие через copy_*_user.

> У нас flat-модель, такое невозможно. Если есть конкретные предложения по реализации - с интересом послушаю. :)

Да что предлагать-то? Оно так и было до версии 2.0 включительно. Фичу зарезали из соображений производительности.

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

> На самом деле, пофиг, ибо всё взаимодействие через copy_*_user.
Не пофиг, а оверхед, если бы нельзя было
напрямую обращаться.

> Фичу зарезали из соображений производительности.
Да поймите вы, АМДшники уже выкинули
сегментную модель из 64битного режима,
а вы всё о 2.0 вспоминаете... Нереализуемо
это на современном железе, да и никто так
не делает сто лет в обед. flat-модель, сто
раз повторяю. :)
Кстати, пруф есть, что в 2.0 было не так?
Что-то слабо верится...

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

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

Это-то я понял. А не вместо нуля? А как узнать нужные значения?

Меня интересует - эта вещь насколько жизнеспособная?

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

> Это-то я понял. А не вместо нуля?
Непонял вопроса... А вместо чего? Вместо
нормально проинициализированного, валидного
указателя? Ну, он же не волшебник... наверное. :)
Благодаря багу, он сумел записать в указатель
ядра нужные ему значения и выпонить код по этому
адресу, забив таким образом на mmap_min_addr.

> Меня интересует - эта вещь насколько жизнеспособная?
По заявлению автора - более жизнеспособная,
чем mmap_min_addr.

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

> А как узнать нужные значения?
Он по определённому адресу разместил
вредоносный код, и хочет, чтобы он
выполнился в режиме ядра.
Адрес этого кода и надо поместить в
тот самый указатель. Раньше это был
нулевой адрес, тк неинициализированный
указатель обычно нулевой. Но придумали
mmap_min_addr, и халява кончилась. Но
и мужик тоже был не пальцем делан - сумел
другие значения класть в указатель, и,
соответственно, по этим адресам клал и
свой код.

anonmyous ★
()

~ $ cat /proc/sys/vm/mmap_min_addr cat: /proc/sys/vm/mmap_min_addr: No such file or directory

~ $ sysctl vm.mmap_min_addr error: "vm.mmap_min_addr" is an unknown key

~ $ uname -r 2.6.27-gentoo-r8

как стать уязвимым? ЧЯДНТ?

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

в догонку к верхнему посту

$ wine --version wine-1.1.12

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

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

А почему положить значение в НЕ инициализированный указатель "легче", чем в нормально проинициализированный. Ведь и в том и в другом случае необходимо производить запись в память по определенному адресу. Как узнать по какому адресу храниться значение указателя?

Buy ★★★★★
()

Больше на Си программируйте.

Nxx ★★★★★
()

GNU/Linux РЕШЕТО!!!

linux-2.6.31.5 Без патчей от grsecurity.net # CONFIG_COMPAT_BRK is not set

gcc-4.3.4 Без pie & ssp разширений glibc-2.9 binutils-2.20

Executable anonymous mapping : Vulnerable Executable bss : Vulnerable Executable data : Vulnerable Executable heap : Vulnerable Executable stack : Vulnerable Executable anonymous mapping (mprotect) : Vulnerable Executable bss (mprotect) : Vulnerable Executable data (mprotect) : Vulnerable Executable heap (mprotect) : Vulnerable Executable stack (mprotect) : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Writable text segments : Vulnerable Main executable randomisation (ET_EXEC) : No randomisation Executable shared library bss : Vulnerable Executable shared library data : Vulnerable

Это будет в каждом дистре за исключением hardened профилей gentoo.

Важное дополнение, архитектура проца x86.

anonymous
()

GNU/Linux РЕШЕТО!!!

linux-2.6.31.5
Без патчей от grsecurity.net
# CONFIG_COMPAT_BRK is not set

gcc-4.3.4
Без pie & ssp разширений
glibc-2.9
binutils-2.20

Executable anonymous mapping : Vulnerable
Executable bss : Vulnerable
Executable data : Vulnerable
Executable heap : Vulnerable
Executable stack : Vulnerable
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
Main executable randomisation (ET_EXEC) : No randomisation
Executable shared library bss : Vulnerable
Executable shared library data : Vulnerable

Это будет в каждом дистре за исключением hardened профилей gentoo.

Важное дополнение, архитектура проца x86.

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

> А почему положить значение в НЕ инициализированный указатель
> "легче", чем в нормально проинициализированный.
Ну он там пишет, что использовал
непроинициализированный указатель
не для исполнения кода, а для
перезаписи данных, и модифицировал
таким образом указатель (другой?),
на нужное ему значение. Как? Я
понятия не имею, это надо эксплойт
копать... Кстати, речь тут не про
оригинальный эксплойт, выложенный
нашедшим уязвимость - тот этого всего
не делает.

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