Линуксокапец

> Кстати в LKML уже появился патч для 2.6.24.1

sS, ты подписан на LKML? Хочу с тобой дружить! :-)

http://lkml.org/lkml/2008/2/10/81

Да нашел я уже :-)

Но все равно спасибо.

> Он решает только _часть_ проблемы

таки эту проблему он решает полностью

Второй который почти у всех работает?

[octy@octylt ~]$ for i in  `seq 1 1000`; do \
/home/octy/jessica_biel_naked_in_my_bed; done

.... (1000 segfaults)

[octy@octylt ~]$ uname -r 
2.6.23-tuxonice-r6-octylt 

[octy@octylt ~]$ cat /etc/gentoo-release
Gentoo Base System release 1.12.10

И после этого кто-то еще будет говорить, что BSD-RIP?

>таки эту проблему он решает полностью

Ну если для вас краш ядра не проблема то тады ой ;)

>sS, ты подписан на LKML?

Долгие годы, а что ? ;)

>Хочу с тобой дружить! :-)

Подпишись тоже - бум дружить ;)

%gcc -o 5092 5092.c
%./5092
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2b2842a48000 .. 0x2b2842a7a000
[+] root
%whoami
root
%rm /usr/local/bin/mutt
%chmod -x /usr/local/bin/flea
%cat /etc/shadow|grep nobody
nobody:x:13914:0:99999:7:::
%uname -a
Linux saahriktu 2.6.24.1 #1 PREEMPT Sun Feb 10 13:09:18 MSK 2008 x86_64 GNU/Linux
%
---
мда... пофиксили...

Такое достаточно часто находят в линухе, баг с ptrace просто оглашался на ЛОРе. Летом в x86_64 коде ядра был какой-то страшный баг, эксплоит присутствовал.

На ядре

Linux xxxxxx 2.6.18-53.1.6.el5.centos.plus #1 SMP Sun Feb 3 10:00:33 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

не работает

Вообще когда линух придет на десктопы то спасением от вирусов как и в виндах будут:


1. urpmi/apt-get/yum по крону
2. не лазить по сайтам с кряками/варезом/порнухой

>Такое достаточно часто находят в линухе,

Ну я как бы не спорю ;)

>баг с ptrace просто оглашался на ЛОРе.

На самом деле баг с ptrace был куда более мощный ;) Он работал по моему на 3-х ветках сразу ;)

>Летом в x86_64 коде ядра был какой-то страшный баг,

Архитектурозависимый баг как раз менее страшен чем такие ...

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

>не работает

Вопрос не в том что не работает а вопрос _как_ не работает ;)

что возвращает vmsplice (retcode)?

В данном случае он обязан возвращать (а значит и обрабатывать) ошибку Bad address в обоих случаях

> не лазить по сайтам с кряками/варезом/порнухой

А вот это не факт. Распространённость вирей на винде является следствием того, что на многие баги просто забивают болт, даже когда те становятся известны вебмастерам на порносайтах.

> Архитектурозависимый баг как раз менее страшен чем такие ...

смотря для какой архитектуры, для x86_64 страшен ибо у нас везде используется :)

Второй работает.

2.6.22.5-31-default сусе 10.3

> Ну если для вас краш ядра не проблема то тады ой ;)

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

Обьясните плз общую концепцию(или дайте линки на описалово),как собственно происходит "заражение/выполнение вредососного кода" при серфинге, я в этом ни бум-бум.

прозреваю ребут linux.org.ru

:)

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

Юзер не знающий root-вого пароля на корпоративном десктопе, вполне может заюзать данный эксплоит

>Крашится не ядро, с сплойт

Из LKML

I was unable to gain root on 2.6.24-git20 but after several segfaults when executing the exploit continously the machine crashes.

В твоём случае PaX ловит попытку выполнения шеллкода который таким образом был записан на стек. Проблема в том что таким способом можно писать всякое дерьмо куда угодно.

Пилять, когда же патч официальный выпустят...

>Пилять, когда же патч официальный выпустят...

Уважай разрабов, выходные же, как-никак. :)

Ну что, допрыгались со своим красноглазым поделием?

BSD rocks.

>BSD rocks

Те напомнить аналогичные плюшки в бздях ? ;)

> В твоём случае PaX ловит попытку выполнения шеллкода который таким образом был записан на стек. Проблема в том что таким способом можно писать всякое дерьмо куда угодно.

Я не особо понимаю как работают эти эксплойты. Но вчера я пробовал отключить возможность исполнения стека с помощью SELinux -- ноль эмоций, эксплойт все равно работает. Вопрос, почему?

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

Проблема в том, что PaX как раз не даёт писать всякое дерьмо куда угодно. Дерьмо можно писать в область данных, а также выполнять можно только соответственно помеченную область.

>Но вчера я пробовал отключить возможость исполнения стека с помощью SELinux -- ноль эмоций, эксплойт все равно работает. Вопрос, почему?

Чего то недоотключил ;)

Патчи, которые делают стек неисполняемым (PaX, OpenWall, grsec, etc) просто ловят трап при обращении к страницам стека а потом пытаются проверить "что это было" ;)

В современных 64-бит процах наконец то добавили аппаратную поддержку "неисполнения" (в спарке оно кстати было с лохматых времён) а вот в ia32 такая возможность отсутствовала и приходилось применять всякие хитрозадые методы например такие http://pax.grsecurity.net/docs/pageexec.txt

Но из за этого имеет место быть некоторый оверхед плюс не работают некоторые извращения, которые позволяет себе gcc. Последнее частично лечится различными способами.

>Дерьмо можно писать в область данных

А этого достаточно ;)

Не работает:

ALT 4.0, Linux 2.6.18-wks-smp-alt2 #1 SMP Sun Feb 25 18:43:34 MSK 2007 i686 GNU/Linux

> А этого достаточно ;)

И выполняться оно оттуда не будет. Читаем полностью, дас.

>И выполняться оно оттуда не будет.

И не надо ;) Можно просто логику программы поменять таким способом ;)

PS: кстати тот же ptrace прекрасно работал на машинах с неисполняемым стеком ;)

hint: баги в ядре нужно фиксить _намертво_, потому как из ядра легко обойти любые заплатки.

Интересно, какие выводы из всего этого сделают разрабы ядра...

Наприме тебе в /proc/sys/kernel/hotplug запишут rm -rf / ;)

>Интересно, какие выводы из всего этого сделают разрабы ядра...

А ты Йенса спроси ;) Это как раз его кусок кода вроде бы ;)

> И не надо ;) Можно просто логику программы поменять таким способом ;)

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

> кстати тот же ptrace прекрасно работал на машинах с неисполняемым стеком ;)

про ptrace не ко мне

> hint: баги в ядре нужно фиксить

никто и не спорит, что надо

> из ядра легко обойти любые заплатки

Если ты уже выполняешься с привелегиями ядра, то да, а если нет, то нет.

>> Интересно, какие выводы из всего этого сделают разрабы ядра...

> А ты Йенса спроси ;)

Спросить-то можно... только вряд ли он ответит :) Интересно, что думат т.н. community

> Наприме тебе в /proc/sys/kernel/hotplug запишут rm -rf / ;)

Для этого надо сначала найти где относительно сплойта торчит hotplug.

> Интересно, что думат т.н. community

То же что и ты и немного больше ;)

>SELinux -- ноль эмоций

ну, наверное он , в отличии от пакса, защищает только юзерспейс.

grsec это МАС-System

> ну, наверное он , в отличии от пакса, защищает только юзерспейс.

Видимо, так и есть. Так ведь абыдна, блин.

Работает на убунту 2.6.22-14. Плохо :-(

да и вабще, SElinux это тоже MAC. Он всего лишь позволяет регулировать работу NX-бита для отдельных приложений. Использовать NX-бит можно и без selinux'а , надо всего лишь включить опцию HIGHMEM64G с соответствующим процессором.

> В современных 64-бит процах наконец то добавили аппаратную поддержку "неисполнения" (в спарке оно кстати было с лохматых времён) а вот в ia32 такая возможность отсутствовала и приходилось применять всякие хитрозадые методы например такие http://pax.grsecurity.net/docs/pageexec.txt

Так я извиняюсь, "наши" эксплойты работают и на x86_64, где бит NX есть. Судя по dmesg, он есть и на моем P-M, только что-то не помогает он.

> да и вабще, SElinux это тоже MAC

/me с этим не спорил. Вопрос почему он при любых комбинациях настроек (в рамках policy), разрешает выполняться эксплойтам.

потому что не для ядра.

вот почитай здесь. авторы grsec и pax мешают РедХэт(execshield/selinux) с дерьмом, обвиняя их в продаже бутафории корпоративным клиентам.

http://www.redhatmagazine.com/2007/05/04/whats-new-in-selinux-for-red-hat-ent...

_____

кстати мне интересно, какого черта в ванилловском воплощении nx-бита, java работает без проблем, а пакс её убивает...

оттуда:

> Yes you can’t protect against all Kernel Attacks, the kernel is
> ring 0, it’s is going to be a weakness for ALL security mechanisms
> (including PaX) in Linux (and any OS).

you’re wrong, it’s not true at all, hasn’t been for the past 4 years at least if we’re talking about PaX. i suggest you check out the KERNEXEC and UDEREF features in PaX, they make entire *classes* of otherwise exploitable *kernel* bugs non-exploitable. case in point, the bug spender’s SELinux exploit abused *cannot* be exploited under UDEREF therefore a grsecurity system was safe whereas SELinux systems weren’t.