[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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-ме.
2. Отсюда выводы:
	а. Если уж очень страшно, всегда есть выбор != i386.
	б. Максимальный системный урон, при выполнении всех пунктов выше
	   == userspace атака _локального_ характера (не уровня ядра).
	   Смысл? Для меня является мало понятным...
	в. Пример/код подобного эксплоита для OpenBSD? url?

> 2. Энтропия адресов при ASLR на x86 гораздо меньше, чем могла бы быть.
> Для сравнения, в PaX/x86 - на 4-8 бит больше.

И? Каков real value? При этом, если уже о PaX, - ни PaX ни exec-shield ещё не
включены в основную поставку ядра Linux. OpenBSD use its W^X daily from 3.3..
А механизма(ов) рандомизации адресного пространства (ASLR), в том виде, в котором
последние сейчас существует вполне достаточно, даже объективно, порою, - перебор.

> 3. PIE появились только недавно (года на 3 позже, чем в тулчейне
> Hardened Gentoo).

Ну да, логично, в OpenBSD и порты достаточно старых версий и не только, i.e.
Apache/1.3.29, etc... А при чём здесь Gentoo?

> 4. Ограничивать или запрещать mprotect(2) для обхода W^X - ни в каком
> виде не хотят, ссылаясь на нежелание нарушать стандарты. При том, что
> 90% софта исполняемые страницы данных/стека не нужны, а mprotect
> довольно широко используется для проведения атак на W^X-подобные защиты.

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

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

Кому полагается и кто кого осуждал?

> 6. Не реализовано никаких защит ядра, аналогичных PAX_MEMORY_UDEREF,
> PAX_KERNEXEC, PAX_RANDKSTACK или иных.

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

> 7. И при этом анализ багов в ядре проводится вяло - энтузиастов нет. Для
> примера можно почитать таймлайн переписки CORE с командой OpenBSD по
> уязвимости в стеке IPv6: CORE пришлось предоставить PoC-эксплойт, чтобы
> в OpenBSD признали уязвимость к выполнению произвольного кода - провести
> анализ самостоятельно опенщики не соизволили и до последнего настаивали
> на DoS-only.

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

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

Извините, каких?

> P.S.
> Не троллинга ради. Просто наболело: всё далеко не так радужно, как
> преподносится и как хотелось бы, а ситуация практически не улучшается.

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

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