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

> А почему положить значение в НЕ инициализированный указатель
> "легче", чем в нормально проинициализированный.
---
My exploit (and many other null ptr dereference exploits) still will
work with a non-executable NULL mapping. The exploit I released was
different from the one I did in 2007 in that in 2007 I abused a function
pointer in the structure that was being pointed to and located at NULL.
In this case, no function pointers were used at all in the structure
being pointed to. I turned a 'trojaned data' situation into an
arbitrary OR of 0x1 and then into arbitrary code execution.
---

Надеюсь, вы всё поняли. :))

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

Забыл дополнить: CONFIG_SECCOMP=y CONFIG_CC_STACKPROTECTOR_ALL=y CONFIG_CC_STACKPROTECTOR=y

> На самом деле, пофиг, ибо всё взаимодействие через copy_*_user.
Кстати, если уж про сегментацию говорить,
то там даже не надо было бы и данные скрывать.
Достаточно для кода сделать разделение, а для
данных - оставить общие адреса.
И, кстати, к 4g/4g split это отношения не
имеет, он делается средствами MMU, а не
сегментацией.
И чтобы небыло подозрений, что я вам мозги
парю на счёт нереализуемости всего этого в
наш век, вот ещё одна цитата:
http://www.pubbs.net/openbsd/200911/4582/
---
2) At least three of our developers were aware of this exploitation
method going back perhaps two years before than the commit, but we
gnashed our teeth a lot to try to find other solutions. Clever
cpu architectures don't have this issue because the virtual address
spaces are seperate, so i386/amd64 are the ones with the big impact.
We did think long and hard about tlb bashing page 0 everytime we
switch into the kernel, but it still does not look attractive from
a performance standpoint.
---
Вряд ли вы будете товарищу Тео про
сегментацию рассказывать, а между тем,
кроме запрета нулевой страницы при
каждом сисколле, он тоже ничего хорошего
не придумал, и ввёл аналог mmap_min_addr...

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

А что в этом плохого? В конце концов есть ещё CR3: указать на другую таблицу виртуальных страниц, где всё юзерспей RO/NX и проблемы не будет. Боюсь только SYSENTER это сам не умеет делать.

> А что в этом плохого?
Ничего.

> В конце концов есть ещё CR3: указать на другую таблицу виртуальных
> страниц, где всё юзерспей RO/NX и проблемы не будет.
Будет приличный оверхед.

> Боюсь только SYSENTER это сам не умеет делать.
Это легко сделать и вручную - 4g/4g split
так и делает. Потом, для доступа к пользовательской
памяти - ещё оверхед.

> где всё юзерспей RO/NX
А почему RO то?

Я немножко глянул Source Navigator'ом в ядро 2.6.25, и мне кажется, что причина этой ошибки находится не совсем там где ее предлагают исправлять. Дело в том, что необходимость проверки указателя на NULL, уже защищенного мьютексом, выглядит более чем странной. Покопав немного код я обнаружил то место которое, скорее всего, и является корнем проблемы. Все в том же pipe.c функция free_write_pipe вызывает free_pipe_info не заботясь о синхронизации. (Во всех остальных вызовах free_pipe_info все ок) Как приду домой обязательно проверю, просто сейчас на работе и немного не до этого. Впрочем, если кто-нибудь пожелает сэкономить мне время и показать что я не прав - welcome :)

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

> функция free_write_pipe вызывает free_pipe_info не заботясь
> о синхронизации.
free_write_pipe() вызывается только в
случае ошибки создания read_pipe в сисколле
pipe2(). Вряд ли при ошибке создания пайпа
ему уже необходима синхронизация...

Имелось в виду вот что: http://lkml.org/lkml/2009/10/14/184

>I went trawling through the code to see if I could figure out how this might have happened. The are mutexes of the form:

> mutex_lock(&inode->i_mutex);

> ...

> mutex_unlock(&inode->i_mutex);

>throughout fs/pipe.c and fs/fifo.c so the above seems to be an impossibility ;-)

И я согласен с Earl Chew, что мьютексы здесь должны страховать от подобных ситуаций. Проблема не столько в отсутствии проверки указателя сколько в самой архитектуре. Существует, пусть крайне маловероятная, возможность закрывать и открывать один и тот же pipe _одновременно_. Другими словами, цикл жизни объекта pipe неопределен. Патч конечно решает данную конкретную проблему, но нет никакой уверенности, что таких проблем нет еще.

>Вряд ли при ошибке создания пайпа ему уже необходима синхронизация...

Да я невнимательно посмотрел, спасибо.

> И я согласен с Earl Chew, что мьютексы здесь должны страховать
> от подобных ситуаций.
Сами по себе мьютексы никому ничего не
должны, и если забывать ставить соотв
проверки, то они и не спасут. :)

> Существует, пусть крайне маловероятная, возможность закрывать и
> открывать один и тот же pipe _одновременно_.
Вот он теперь и проверяет, а не был
ли пайп уже закрыт. Какие подозрения
это может вызывать?

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

А может быть вы и правы, что
не должен он был так далеко зайти
при нормальной расстановке мьютексов...
Ведь если, допустим, уже заведомо
закрытый пайп передать, то он же не
на этих проверках вывалится, а гораздо
раньше... Так что х/з, попробуйте свой
фикс сделать, может и правда, что хорошее
выйдет. :)

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

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

Судя по каментам большинство думает, что Linux вирусы это несерьёзно. Но напомню, что примерно так же думали юзвери 4BSD, Sun3, MS DOS и PC DOS в 80-х годах перед появлением червя Морриса и вируса Blaster...

Всё серьёзно, Ubuntu шагает по десктопам. По счастью, порядок серьёзности намного ниже, чем в лагере Win*.

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

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

Это вообще что? На каком языке? От рута пускать надо?

systemtap. да.