Улучшения связанные с безопасностью, ожидаемые в будущем релизе Debian

> я не это имел ввиду. загляни в /etc/passwd, /etc/group. Зачем на десктопе такая куча групп и пользоватей ? Зачем на десктопе разграничение прав доступа к устройствам по группам ?

Что это ещё за нафиг? Виндузятник? Почему у меня это не вызывает недовольство, а у Вас вызывает? Я прихожу с работы домой и вижу ту же организацию ОС, что и на работе - это удобно. Для кто не грузится администрированием должно быть просто пофиг - система все операции с групами делает сама, в принципе. Так что, возникновение подобных вопросов, вообще, странно.

>Stack protector - сборка пакетов с включенной в GCC опцией "-fstack-protector" для защиты от атак, направленных на переполнение буфера и стека.

"-fstack-protector" очень мало! Надо делать "-fstack-protector-all", а ещё лучше "-fPIE -fstack-protector-all" +PAX но для этого надо сообществам дистрибутивов не ругаться между собою, а сесть вместе и добить pie для gcc-4* как это уже сделали для ssp...

Ну после того как дебиановци прикончили свой hardened debian остался только Hardened Gentoo!

>хорошо. Предлагаешь дистрибутиву держать две ветки системного софта - один для серверов, другой для десктопа? Или уходить с одного из рынков?

Давно пора объединится с убунтой и разделить сервер-десктоп по командам разработчиков.

неправильная(тенденциозная и [намеренно?]подслеповатая) калькуляция. считаем усредненную среднюю процессорную мощу(как минимум - 2-х я дерную), считаем издержки от ЕДИНИЧНОЙ проблемы в этой области. финиш, выносят актеров, генсек фирмы - умоялет сказать, куда ему еще МОЖНО потратить деньги.

+ если уж вантузятнек, то может работать и под рутом.

а если нормальный человек, то добавит себя в группы audio и cdrom и не будет мучаться этими вопросами

>Давно пора объединится с убунтой и разделить сервер-десктоп по командам разработчиков.

Нафиг. Не хочу себе убунту на десктоп. Жить будет можно, а жить хорошо - не факт.

> неправильная(тенденциозная и [намеренно?]подслеповатая) калькуляция. считаем усредненную среднюю процессорную мощу(как минимум - 2-х я дерную), считаем издержки от ЕДИНИЧНОЙ проблемы в этой области. финиш, выносят актеров, генсек фирмы - умоялет сказать, куда ему еще МОЖНО потратить деньги.

У вас в фирме на десктопах используется линукс? :)

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

> Не прошло и двух (или трёх?) лет как в Debian появились фишки из Fedora. :-)

В ubuntu есть давно.

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

Ты дурак? А если переполнение при обработке JPG/BMP/GIF/PDF? Предпочтешь спам-ботов с линукса вычищать или ты через telnet в Интернет ходишь(в котором, теоретически, тоже могут быть переполнения)?

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

>+1. Выходит gentoo - true way.

А зачем на десктопе разеление прав? Лишнее! А почему графика не в ядре? Windows 95 - true way.

так уж прям совсем и не в ядре? ((: а radeon.ko, drm.ko и тд - они где? в астрале?

> я не это имел ввиду. загляни в /etc/passwd, /etc/group. Зачем на десктопе такая куча групп и пользоватей ?

Для безопасности. Один сервис - один юзер. Чтобы взлом сервиса не давал привилегий root как в одной альтернативной системе.

> Зачем на десктопе разграничение прав доступа к устройствам по группам ?

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

> тебе /usr дороже /home ? мне - нет.

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

> я не это имел ввиду. загляни в /etc/passwd, /etc/group. Зачем на десктопе такая куча групп и пользоватей ?

Именно потому, что UNIX пришли с серверов, где были изначально разграничены права, на десктопы мы и не наблюдаем тучи remote root-ов в службах и проблем с работой программ не под локальным администратором-рутом, котоыре наблюдаются в альтернативной системе, которая пришла с однопользовательских ПК без разграничения прав на рабочие станции и сервера притащив с собой детские болезни.

> "-fstack-protector" очень мало! Надо делать "-fstack-protector-all", а ещё лучше "-fPIE -fstack-protector-all" +PAX но для этого надо сообществам дистрибутивов не ругаться между собою, а сесть вместе и добить pie для gcc-4* как это уже сделали для ssp...

NX+ASLR(+vdso=1) и доп. проверки во free() введенные в libc 2.3 - уже дофига и больше. -fstack-protector лишь добьет _теоретическую_ возможность эксплуатации переполнения буфера на стеке. Покажите хоть один PoC эксплоит для переполнения буфера на стеке, который работает с включенным по умолчанию kernel.randomize_va_space=1(ASRL)

> Нафиг. Не хочу себе убунту на десктоп. Жить будет можно, а жить хорошо - не факт.

Факт. Ubuntu это тот же Debian только свежий, с частыми релизами и ориентированный на масовый десктоп, набитый фирмварью, собранными модулями для кучи разных настольных железок, с субпиксельным рендерингом и с простым вылизанным _стандартизованным_ GUI. И -fstack-protector там, кстати, есть уже давно. Фактически, сфера влияния уже поделена: Debian Stable(+backports) - сервер, Ubuntu - десктоп.

>Нафиг. Не хочу себе убунту на десктоп. Жить будет можно, а жить хорошо - не факт.

Сейчас не факт. Я тоже не хочу убунту. А когда это будет единое целое - жить будет хорошо.

Хорошо бы, на самом деле..

>NX+ASLR(+vdso=1) и доп. проверки во free() введенные в libc 2.3 - уже дофига и больше. -fstack-protector лишь добьет _теоретическую_ возможность эксплуатации переполнения буфера на стеке.

"уже дофига и больше" - я не понимаю сколько это..

У меня есть такое понятие как необходимо, а есть ещё понятие достаточно. Разницу чувствуешь?

>Покажите хоть один PoC эксплоит для переполнения буфера на стеке, который работает с включенным по умолчанию kernel.randomize_va_space=1(ASRL)

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

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

> Покажите хоть один PoC эксплоит для переполнения буфера на стеке, который работает с включенным по умолчанию kernel.randomize_va_space=1(ASRL)

А гуглить не пробовали? Их полно. Вот примеры: http://milw0rm.org/papers/55 http://www.phrack.org/archives/61/p61-0x06_Advanced_malloc_exploits.txt

Рандомизацию mmap и некоторые другие тоже обходят - правда, в основном на i386, на x86-64 они более-менее работают. Просто банально адресного пространства в 32-х битной системе не хватает для хорошей рандомизации (она же не "честная" - нельзя что угодно куда попало пихать, работать просто не будет). Вообще если почитать различные PoC, большинство этих методов защиты на i386 как мертвому припарки.

> У меня есть такое понятие как необходимо, а есть ещё понятие достаточно. Разницу чувствуешь?

Мер, достаточных для обеспечения 100% безопасности не существует.

> "уже дофига и больше" - я не понимаю сколько это..

Ну а в каких попугаях пользу от PAX или -fstack-protector считаешь ты? еаперед могу сказать, что -fstack-protector - не панацея, потому что существует вероятность, что кто-то научится предсказывать или случайно сможет угадать 8 байт маркера между буфером на стеке и адресом возврата, по которому определяется произошло переполнение или нет.

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

Как страшно жить. (с) Фундаментальные методы эксплуатации всегода всплывали во phrack и подобных ему специфических изданиях. А общепринятая оценка стойкости средств защиты или криптостойкость алгоритмов шифрования оцениваются не по сказкам про мегахакеров, а по исследовательским работам, доказывающим ненадежность используемого алгоритма и PoC-эксплоитам, демонстрирующим всю реальность имеющейся угрозы. man full-disclosure > Я питаюсь уже во второй теме разказать о стратегии, что о точьной уязвимости никто не знает до момента её выявления но существует инструментарий защиты даже от теоретически возможных уязвимостей.

Именно так, ASLR, -fstack-protector, NX - средства защиты от эксплуатации неизвестных уязвимостей, связанных _только_ с переполнением буфера. chroot, jail, MAC/RBAC(SELinux/GrSec), виртуализация - средства локализации и минимизации ущерба от эксплуатации любых неизвестных уязвимостей.

> У меня есть такое понятие как необходимо, а есть ещё понятие достаточно. Разницу чувствуешь?

Мер, достаточных для обеспечения 100% безопасности не существует.

> "уже дофига и больше" - я не понимаю сколько это..

Ну а в каких попугаях пользу от PAX или -fstack-protector считаешь ты? Наперед могу сказать, что -fstack-protector - не панацея, потому что существует вероятность, что кто-то научится предсказывать или случайно сможет угадать 8 байт маркера между буфером на стеке и адресом возврата, по которому определяется произошло переполнение или нет. То же самое касается и ASLR. Неисполнимые сегменты, которые реализуются аппаратно(SPARC, AMD64) или с помощью трюков PAX на x86 - уязвимы для атак класса ret-in-libs. Вот такие дела.

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

Как страшно жить. (с) Фундаментальные методы эксплуатации всегда всплывали во phrack и подобных ему специфических изданиях. А общепринятая оценка стойкости средств защиты или криптостойкость алгоритмов шифрования производились не по сказкам про мегахакеров, а по исследовательским работам, доказывающим ненадежность используемого алгоритма и PoC-эксплоитам, демонстрирующим всю реальность имеющейся угрозы. man full-disclosure и man традиционная открытость алгоритмов шифрования.

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

Именно так, ASLR, -fstack-protector, NX - средства защиты от эксплуатации неизвестных уязвимостей, связанных _только_ с переполнением буфера. chroot, jail, MAC/RBAC(SELinux/GrSec), виртуализация - средства локализации и минимизации ущерба от эксплуатации любых неизвестных уязвимостей.

Они убили Lenny =D

>Ты дурак? А если переполнение при обработке JPG/BMP/GIF/PDF? Предпочтешь спам-ботов с линукса вычищать или ты через telnet в Интернет ходишь(в котором, теоретически, тоже могут быть переполнения)? anonymous (*) (02.02.2008 0:26:26)

Э-э-э... А их компилировать надо, или сами запустятся??? Или вы про оффтопик?

> А гуглить не пробовали? Их полно.

Пробовал. И phrack читал. И с написанием реальных эксплоитов когда-то игрался.

Вот это, к примеру, сто лет как неактуально: http://www.phrack.org/archives/61/p61-0x06_Advanced_malloc_exploits.txt

$ ./got_bf

## HINTED LIBC GOT BRUTEFORCING PoC ##

(-) 512 bytes shellcode @ 0x804a008
*** glibc detected *** ./got_bf: free(): invalid pointer: 0xb7d9a0d0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7e31d65]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7e35800]
./got_bf[0x80486ee]
./got_bf[0x804883f]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7dde050]
./got_bf[0x8048511]
======= Memory map: ========

Это: http://milw0rm.org/papers/55 - более интересно. Но, похоже,
рассчитано на то, что VDSO всегда находится по фиксированному адресу
0xFFFFE000, а я не зря упомянул параметр ядра vdso=1, отключающий
совместимое поведение VDSO там, где ядро собрано с
CONFIG_COMPAT_VDSO. Вот как работает PoC на ядре 2.6.24 с рандомизованным VDSO(без CONFIG_COMPAT_VDSO):

esp bfbb51d0 error 4
$ ./vaexploit-poc
Segmentation fault
$ dmesg|tail -1
[24672.000998] va-exploit-poc[8289]: segfault at ffffe000 eip 080483f0 esp bf80d4c0 error 4

(gdb) r
Starting program: /home/anonymous/stuff/va-exploit-poc

Program received signal SIGSEGV, Segmentation fault.
0x080483f0 in find_esp ()
(gdb) x/i $eip
0x80483f0 <find_esp+28>: movzbl (%eax),%eax
(gdb) i r eax
eax 0xffffe000 -8192

На 2.6.22 c vdso=1 рез-т аналогичен. Уверен что на более ранних ядрах с CONFIG_COMPAT_VDSO или vdso=1 будет тот же.

Однако системы Debian etch с 2.6.18 и Ubuntu до gutsy с 2.6.22(в hardy
выкинули VDSO_COMPAT) по умолчанию(параметр vdso=1 по умолчанию не
активирован) уязвимы к обходу ASLR через VDSO_COMPAT, как и
вообще любые систем и самосбор с CONFIG_COMPAT_VDSO:

$ ./va-exploit-poc
* Found JMP %ESP @ 0xffffe777
sh-3.1$ exit

НО если бинарь собран gcc-4(а это большинство существущих сегодня) то даже без stack-protector:

(gdb) r
Starting program: /tmp/va-exploit-poc
Failed to read a valid object file image from memory.
* Found JMP %ESP @ 0xffffe777

Program received signal SIGSEGV, Segmentation fault.
0x08048392 in __do_global_dtors_aux ()

(gdb) x/i $eip
0x8048392 <__do_global_dtors_aux+34>: ret
(gdb) x/4i $eip-5
0x804838d <__do_global_dtors_aux+29>: pop %ecx
0x804838e <__do_global_dtors_aux+30>: pop %ebp
0x804838f <__do_global_dtors_aux+31>: lea 0xfffffffc(%ecx),%esp
0x8048392 <__do_global_dtors_aux+34>: ret

Т.е. из-за ссылки на %ecx перед возвратом, если переписывается
сохраненный %ecx на стеке, то %esp восстанавливается фиг знает откуда
и возврат происходит фиг знает куда. При этом база стека иеняется от
запуска к запуску т.к. ASLR, поэтому аккуратно предсказать и переписать
образ %ecx и образ %esp на стеке, чтобы выполнить шеллкод не получится...
Поэтому все вышеперечисленные способы эксплуатации переполнений кучи и обхода ASLR - туфта. :D

Добавление к последнему:

(gdb) x/4i $eip-5 0x804838d <__do_global_dtors_aux+29>: pop %ecx 0x804838e <__do_global_dtors_aux+30>: pop %ebp 0x804838f <__do_global_dtors_aux+31>: lea 0xfffffffc(%ecx),%esp 0x8048392 <__do_global_dtors_aux+34>: ret (gdb) i r ebp ebp 0x41414141 0x41414141 (gdb) i r ecx ecx 0x41414141 1094795585 (gdb) i r esp esp 0x4141413d 0x4141413d (gdb)

Видно, что из-за переполнения переписались сохраненные значения EBP и ECX, а после команды lea 0xfffffffc(%ecx),%esp получим

ESP=ECX-12

А поскольку образ ECX был переписан мусором, то и получаем сегфолт при ссылке по мусору при выполнении команды ret. Для того, чтобы не было сегфолта и чтобы суметь возвратиться на шеллкод нужно угадать правильный адрес в ECX, но база стека плавает(ASLR) и сохраненный в ECX адрес тоже, т.е. задача снова сводится к борьбе с ASLR...

Добавление к последнему:

(gdb) x/4i $eip-5
0x804838d <__do_global_dtors_aux+29>: pop %ecx
0x804838e <__do_global_dtors_aux+30>: pop %ebp
0x804838f <__do_global_dtors_aux+31>: lea 0xfffffffc(%ecx),%esp
0x8048392 <__do_global_dtors_aux+34>: ret
(gdb) i r ebp
ebp 0x41414141 0x41414141
(gdb) i r ecx
ecx 0x41414141 1094795585
(gdb) i r esp
esp 0x4141413d 0x4141413d
(gdb)

Видно, что из-за переполнения переписались сохраненные значения EBP и ECX, а после команды lea 0xfffffffc(%ecx),%esp получим

ESP=ECX-12

А поскольку образ ECX был переписан мусором, то и получаем сегфолт при
ссылке по мусору при выполнении команды ret. Для того, чтобы не было сегфолта и
чтобы суметь возвратиться на шеллкод нужно угадать правильный адрес
в ECX, но база стека плавает(ASLR) и сохраненный в ECX адрес тоже, т.е.
задача снова сводится к борьбе с ASLR...

> Э-э-э... А их компилировать надо, или сами запустятся??? Или вы про оффтопик?

Святая детская наивность, наслушавшаяся сказочек про вирусы которые нужно компилировать. Для запуска шеллкода даже сервисы libc не требуются, достаточно системных вызовов int 0x80 на x86 и syscall на AMD64.

На вот пруф: http://slil.ru/25429165

Работает на совершенно любом любом ядре Linux x86 и AMD64(с CONFIG_IA32_EMULATION).

> Просто банально адресного пространства в 32-х битной системе не хватает для хорошей рандомизации (она же не "честная" - нельзя что угодно куда попало пихать, работать просто не будет)

База стека на 32-битной системе из-за ASLR пляшет в интервале 0xbf800000-0xc0000000 c шагом в страницу памяти(4096 байт). Вероятность угадать базу(а конкретный адрес на стеке зависит еще и от бинарной сборки) составляет: 1/((3221225472-200802304)/4096)=0.00000135610137128970 или около одного шанса на миллион!

>Во многих дистрах правда это уже есть. timur_dav (*) (01.02.2008 12:59:22)

вомногих этого нет )

А что нам скажет товагищь Тгоцкий?

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

как только количество десктопов на линуксе достигнет значимого числа, будет написан червь которые объединит их в ботнеты. зачем им твой компьютер ? да спам рассылать и в ддос атаках участвовать. как тут уже было верно замечено, микрософт тоже думал что безопасность на десктопе не нужна.

>>Значит ты на своем десктопе занимаешься херней и ничего ценного у тебя в ~ нет. Видимо, твоя цель это вечная компиляция программ в /usr, поэтому риск потерять многочасовые накомпилированные наработки тебя и пугает.

осиль ещё раз фразу "тебе /usr дороже /home ? мне - нет."

> осиль ещё раз фразу "тебе /usr дороже /home ? мне - нет."

Эээ ошибся. Я отвечал на это:

> Снёс половину /home. Если бы я снёс половину /usr - было бы намного хуже...