Re: [openbsd] Re: fwd: [nick@holland-consulting.net: Supporting OpenBSD]

[Pavel Labushev <p.labushev@gmail.com>]

Sergey Prysiazhnyi пишет:
> On Thu, Sep 10, 2009 at 12:09:06AM +0800, Pavel Labushev wrote:
>> Sergey Prysiazhnyi пишет:
>> 1. С 2004 года не закрывают уязвимость к обходу W^X путём возврата на
>> retf. Даже невзирая на то, что в документации к SEGMEXEC в PaX от начала
>> 2003 (!) года эта тема затронута и рассмотрена отдельно.
> 
> 0. Данная "уязвимость" архитектуро-зависима.
> 1. Вы вероятно об этом: http://www.openbsd.org/papers/auug04/mgp00014.html
>    Здесь хотелось бы напомнить о том, что для подобного рода атаки на retf Вам
>    необходим _правильно_ подготовленный стек! + не забываем об SSP, как минимум,
>    + random как на стеке, так и о 'библиотечном' random-ме.

Вы сейчас начали объяснять, почему проблема с retf якобы не так страшна.
Но суть-то не в том, что не так страшна, а в том, что _замалчивается_ и
не решается уже чёрте с какого года.

Вы увлеклись рандомом, но забыли (?), что он выеденного яйца не стоит в
случае с атаками на prefork-приложения, а также в случае уязвимостей к
раскрытию данных на стеке. И SSP здесь не всегда помощник. Вот вам и
уязвимые серверы.

А между тем, в Grsecurity/PaX есть простое и достаточно эффективное
средство противостояния таким атакам - это 30-секундная задержка (в
исходниках можно запросто поправить хоть до минуты и более, с оглядкой
на tcp-таймауты) fork'а родителя, ребёнок которого был уличён в
неудачной попытке выполнить произвольный код. Вы даже можете
анализировать логи и перезапускать родителя в таких случаях - полная
автоматизация и никакого ночного бдения.

Далее. SSP бывает не включён при сборке некоторых приложений. Как
правило это особенно сложные и глючные (читай: более уязвимые) поделия,
вроде OpenOffice. Вот вам и уязвимые десктопы (менее, но всё-таки).

> 2. Отсюда выводы:
> 	а. Если уж очень страшно, всегда есть выбор != i386.

Пусть эту проблему и её решение где-нибудь документируют - вопросов не
будет. А пока есть только пафосная презентация от 2004-го года, в
которой эти аспекты замалчиваются.

> 	б. Максимальный системный урон, при выполнении всех пунктов выше
> 	   == userspace атака _локального_ характера (не уровня ядра).
> 	   Смысл? Для меня является мало понятным...

Ну, во-первых, не всех пунктов, а лишь некоторых, а иногда и того не
надо - _гарантированно_ сработает простой брутфорс.

Во-вторых, если атака локального характера, это как минимум значит:
1. Компрометация/потеря/повреждение данных, доступных
скомпрометированному процессу. А это может быть почта, базы данных,
ключи, сертификаты. Особенно сертификаты! Стоит один раз прошляпить
компрометацию - в большинстве случаев можете забыть о защите от MitM
даже после отзыва, т.к. с CRL клиенты чаще всего не работают или
работают "чисто символически" (не обновляют).
2. Присутствие атакующего на системе с потенциальной реализацией
незакрытых (в т.ч. неопубликованных) уязвимостей в других компонентах.
3. Опасность эксплуатации неопубликованных или незакрытых уязвимостей в
ядре,  которое не защищено по аналогии с линукс-ядром в PaX/x86,
незвирая на ваши надежды.
4. Проведение атаки на другие узлы, недоступные напрямую из внешних
сегментов сети. Со всеми вытекающими.

При этом сколько-нибудь внятных средств HIDS/HIPS в опене нет. Тогда как
в том же Grsecurity есть замечательный RBAC.

Если напомнить об этом опенщикам, они наверняка включат мантры "RBAC/MAC
is unnecessary overcomplication, we prefer simpler solutions"... Но при
этом их почему-то устраивает systrace, уязвимый к подмене аргументов,
копируемых ядром из юзерленда по указателям. В линукс-версии systrace
реализован тот самый look-aside буфер для защиты от подмен, которого до
сих пор нет в опене. Ну хоть документировали уязвимость к подмене в man
systrace - спасибо и на этом.

А знаете, почему нет буфера? Потому что systrace давно лёг в систему и
лежит там мёртвым грузом. Допиливать его никто не хочет, потому что
никто им не пользуется, а выкинуть, видимо, религия не позволяет, хотя в
письме, которое вы сюда отфорвардили, заявляется как раз об обратном.
Вот такие, вот, "simpler solutions" и "great quality"...

> 	в. Пример/код подобного эксплоита для OpenBSD? url?

http://www.cr0.org/misc/obsdretf.asm

>> 2. Энтропия адресов при ASLR на x86 гораздо меньше, чем могла бы быть.
>> Для сравнения, в PaX/x86 - на 4-8 бит больше.
> 
> И? Каков real value? При этом, если уже о PaX, - ни PaX ни exec-shield ещё не

$ paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete

Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux worm3 2.6.30.5-grsec-200909052209 #10 SMP Mon Sep 7 13:37:10 KRAST
2009 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD
GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 18 bits (guessed)
Heap randomisation test (ET_EXEC)        : 24 bits (guessed)
Heap randomisation test (ET_DYN)         : 24 bits (guessed)
Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
Main executable randomisation (ET_DYN)   : 16 bits (guessed)
Shared library randomisation test        : 18 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)
Return to function (strcpy)              : Killed
Return to function (memcpy)              : Killed
Return to function (strcpy, RANDEXEC)    : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

$ uname -a
Linux desktop 2.6.30.5-grsec-200909052209 #10 SMP Mon Sep 7 13:37:10
KRAST 2009 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
AuthenticAMD GNU/Linux

> А механизма(ов) рандомизации адресного пространства (ASLR), в том
> виде, в котором последние сейчас существует вполне достаточно, даже
> объективно, порою, - перебор.

Объективно - как раз недобор. Особенно в случае с prefork или при атаках
 на уникальные, но постоянно запускающиеся процессы. У вас на серверах,
что ли, prefork-демонов нет?

> включены в основную поставку ядра Linux. OpenBSD use its W^X daily from 3.3..

Во-первых, какая разница, включены или нет? Есть реализация защит
рантайма от PaX, а есть от OpenBSD. Причём качество последней не зависит
от "качества" прочего говнокода в ядре линукса. Я сравниваю реализации,
чтобы на реальном примере показать: в опене может быть лучше, чем сейчас.

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

> А механизма(ов) рандомизации адресного пространства (ASLR), в том виде, в котором
> последние сейчас существует вполне достаточно, даже объективно, порою, - перебор.
> 
>> 3. PIE появились только недавно (года на 3 позже, чем в тулчейне
>> Hardened Gentoo).
> 
> Ну да, логично, в OpenBSD и порты достаточно старых версий и не только, i.e.
> Apache/1.3.29, etc... А при чём здесь Gentoo?

Причём здесь порты вообще? Речь о Position Independent Executables, в
т.ч. в базовом юзерленде.

А Gentoo здесь при том, что там PIE появились года 3 назад, если не
больше. И это всего лишь доработка защиты рантайма, которой опенщики, с
их претензиями на великое качество всего и вся, должны (should) были
озаботиться, как минимум, не сильно позже той же генты.

>> 4. Ограничивать или запрещать mprotect(2) для обхода W^X - ни в каком
>> виде не хотят, ссылаясь на нежелание нарушать стандарты. При том, что
>> 90% софта исполняемые страницы данных/стека не нужны, а mprotect
>> довольно широко используется для проведения атак на W^X-подобные защиты.
> 
> Хм, немного не понял. Но, всё же:
> http://www.openbsd.org/goals.html s/standard
> mprotect(2) - наследие 4.4BSD.
> "довольно широко используется для проведения атак на W^X-подобные защиты".
> Как? Пример?

Вас в гугле, простите, забанили?

Знаете, что удивительно? Вот вы принимаете на веру и надежду заявления
команды OpenBSD о безопасности и качестве, а проверить их самостоятельно
 - банально ленитесь (?). Такое впечатление складывается. И при этом
спорите, не будучи в курсе самих азов. Вот как будто вы сами не
заинтересованы, а разговор у нас ни о чём и ваши же интересы никак не
затрагивает.

>> 5. Нет документации по механизмам защиты рантайма (а ведь она необходима
>> для прохождения peer review, как полагается) - в лучших традициях
>> осуждаемого линукса.
> 
> Кому полагается и кто кого осуждал?

Да регулярно. Разрабы OpenBSD ругают линукс. Ну, в самом деле? Неужели
вы misc@ не читали?

> Что-то мы сегодня много о PaX... По поводу "Не реализовано", а Вы где смотрели?
> options(4) + самый верный вариант - man 9 intro + /usr/src/sys/

Да я-то как раз в исходниках смотрел и в логах CVS. А вот вы где
смотрели? В манах и презентациях? Так там и смотреть не на что (в
буквальном смысле) на эту тему.

А PaX я привожу в качестве примера для сравнения. Фундаментальных
различий в подходах к управлению памятью между опеном и линуксом
практически нет, так что сравнение вполне корректно.

> По поводу энтузиастов, you are welcome... 

Госсподи, опять shut up and code? Да если бы дело было только в
недовольстве функционалом, я бы и не заикался. Но дело-то ещё и в том,
что никто официально об этих слабых сторонах опена не говорит. Говорят
совсем об обратном: мол, уж если мы что и делаем, то делаем очень
качественно [, можете нам доверять]. Вот и вы очередное фанфарное письмо
отфорвардили. А на деле-то: защита рантайма трещит по швам.

> А, объективно говоря о IPv6, последний
> ещё настолько сырой и далёкий от стабильного состояния, что уязвимости - скорее
> норма в данном контексте.

Ну так кто бы сомневался. Однако суть моего примера не в IPv6, а в
нежелании опенщиков анализировать security-related баги в ядре. А это,
на мой взгляд, просто нарадоксально для системы, которая заявляет о
себе, как о самой защищённой (или одной из), и говорит о _проактивном_
подходе к ИБ (в том числе об аудите! - ну и где этот аудит?). Да и
просто нечестно по отношению к пользователям.

>> 8. Реализация органичений chroot(2) оставляет желать лучшего: как
>> минимум, некоторых из тех простых и эффективных вещей, которые давно
>> есть в Grsecurity.
> 
> Извините, каких?

http://www.grsecurity.net/features.php (Chroot restrictions)

> Здесь без комментариев. 
> http://www.openbsd.org/images/hackathons/c2k9.gif

Да ладно вам... "Без комментариев"... Ваш "shut up and code" был бы
уместен в случае, когда юзер чем-то не доволен и жалуется сугубо по
этому поводу. Но в данном-то случае имеет место введение пользователя в
заблуждение - совсем другой разговор! Опенщики делают акцент на
проактивные подходы в безопасности, на аудит кода, а на деле... Я уже
сказал.

-- 
To unsubscribe send an e-mail to openbsd+unsubscribe@uaoug.org.ua
For retrieval in messages archive http://www.uaoug.org.ua/archive