LINUX.ORG.RU
Форум — Talks  

Local root exploit for CVE-2014-0038

 , , ,


0

1

https://github.com/saelo/cve-2014-0038

Локал рут, требует CONFIG_X86_X32=y. Изкоробочно для убунты, но кроссдистрибутивно (зависит от ядра, 3.4+). https://github.com/seletskiy/cve-2014-0038/commit/d8daf0ff41dfad72a0d59dcac4a... — пример патча для ядра 3.8.

http://seclists.org/oss-sec/2014/q1/187 — подробнее об уязвимости.

Кому не лень — оформит новость.

При чём тут убунта: https://bugzilla.redhat.com/show_bug.cgi?id=854317 — реквест включить X32 в федоре rejected из-за бесполезности и возможности проблем с безопасностью.

Если не работает: не забывать, что там захардкожены некоторые адреса. Смотреть в /proc/kallsyms (читабелен рутом, собственно, с самосборными ядрами не так страшно). По ссылке захардкожен вариант для дефолта убунты, но никто не мешает сделать по версии на дефолты арча и зузи.

★★★★★

Последнее исправление: x3al (всего исправлений: 4)

Да, именно поэтому у меня генту везде где можно и дебиан где нельзя.

wakuwaku ★★★★
()

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

P.S. Для паникёров — X32 это не x86_32 и не IA32 и вообще совсем другое.

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

Этому CVE дня три. X32 включен по дефолту в свежей убунте, отсюда теги.

Минус эксплойта: зависим от версии ядра. Но работает практически везде, если X32 таки включен.

x3al ★★★★★
() автор топика

https://bugzilla.redhat.com/show_bug.cgi?id=854317 — реквест включить X32 в федоре rejected из-за бесполезности и возможности проблем с безопасностью.

Так тот реквест уже давно протух. За ненужностью.

Reported: 2012-09-04 11:42 EDT by H.J. Lu

Last Closed: 2013-04-05 15:37:40

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

О чём и речь. В убунте больше смелых экспериментаторов, которые точно знают, зачем им X32.

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

В убунте больше смелых экспериментаторов, которые точно знают, зачем им X32.

А можно примеры этих смелых экспериментов?

Siado ★★★★★
()

При чём тут убунта

а как обстоят дела в дебиане?

Update: зачем нужен CONFIG_X86_X32=y ? без него и так 32-ух битные бинарники запускаються.

snaf ★★★★★
()
Последнее исправление: snaf (всего исправлений: 1) 
!gre
grep 'CONFIG_X86_X32' /boot/config-3.11.2 
# CONFIG_X86_X32 is not set

Проблемы негров дебианщика не е*ут.

darkenshvein ★★★★★
()

Убунта. Уже пару минут висит на «waking up parent...», дальше он должен дать мне рут, но не даёт.

CYB3R ★★★★★
()

Во-во. Вперёд и с песней. «Я бедный афглинуксовый вирус; прошу сохранить этот архив на ФС с exec, распаковать и выполнить sudo ./configure (судя по kallsyms) && make && sudo make install».

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Stahl

Для паникёров — X32 это не x86_32 и не IA32 и вообще совсем другое

Да что ты говоришь.

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

Така же история но в арче.. парент сказал address can't be written to, not a valid timespec struct и вышел, а деточка ждет и не знает, что нет его больше. Я вот думаю, 

#define __X32_SYSCALL_BIT 0x40000000
#undef __NR_recvmmsg
#define __NR_recvmmsg (__X32_SYSCALL_BIT + 537)
а точно для всех ядер __NR_recvmmsg живет по этому адресу?

naszar ★
()

Во-первых: баян. Во-вторых: хомячьё должно страдать.

mbwa ★
()

Не актуально. Это только для олдфагов, использующих X86_X32. Для систем на базе amd64 - это не актуально.

lucentcode ★★★★★
() 
david@InTreat ~/cve-2014-0038 $ ./a.out 
preparing payload buffer...
changing kernel pointer to point into controlled buffer...
clearing byte at 0xffffffff81fb312f
waiting 255 seconds...
0s/255s
10s/255s
20s/255s
30s/255s
40s/255s
50s/255s
60s/255s
70s/255s
80s/255s
90s/255s
100s/255s
110s/255s
120s/255s
130s/255s
140s/255s
150s/255s
160s/255s
170s/255s
180s/255s
190s/255s
200s/255s
210s/255s
220s/255s
230s/255s
240s/255s
250s/255s
waking up parent...
byte zeroed out
clearing byte at 0xffffffff81fb312e
waiting 255 seconds...
0s/255s
10s/255s
20s/255s
30s/255s
40s/255s
50s/255s
60s/255s
70s/255s
80s/255s
90s/255s
100s/255s
110s/255s
120s/255s
130s/255s
140s/255s
150s/255s
160s/255s
170s/255s
180s/255s
190s/255s
200s/255s
210s/255s
220s/255s
230s/255s
240s/255s
250s/255s
waking up parent...
byte zeroed out
clearing byte at 0xffffffff81fb312d
waiting 255 seconds...
0s/255s
10s/255s
20s/255s
30s/255s
40s/255s
50s/255s
60s/255s
70s/255s
80s/255s
90s/255s
100s/255s
110s/255s
120s/255s
130s/255s
140s/255s
150s/255s
160s/255s
170s/255s
180s/255s
190s/255s
200s/255s
210s/255s
220s/255s
230s/255s
240s/255s
250s/255s
waking up parent...
byte zeroed out
releasing file descriptor to call manipulated pointer in kernel mode...
Killed
david@InTreat ~/cve-2014-0038 $ lsb_release -d
Description:	Linux Mint 16 Petra

Не робит.

shuck ★★★
()

У меня не заработало... Правда у меня вообще ARM на серваке...

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

Да в курсе я, что это такое. Не понимаю, зачем использовать 32-битные указатели в системе на базе 64-битного ядра. Нужно использовать чистую 64-битную систему, и не париться.

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

Я не верю результатам бенчмарков. Для меня важен мой личный комфорт. А 64-битная система позволяет мне комфортно работать. В отличии от 32-битной.

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

Сам виноват — поставил арч. Теперь будешь патчить каждый эксплойт.

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

naszar ★
()
Последнее исправление: naszar (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks