> Не совсем понял фразы "общий стек": для каждого потока выполнения в ядре
> свой стек. Но добраться до этого стека при условии, что мы

Имелся ввиду общий стек системных вызовов.

> Другое дело, что возможность считать произвольный адрес в памяти несёт в себе
> столько потенциальных угроз (вроде считывания ключей IPSec), что в гроб ложиться
> можно сразу. Так что я бы не стал заморачиваться утаиванием канарейки,

"Чтение произвольного адреса" бывает разным - это может быть и off-by-one, и частично подконтрольное атакующему значение смещения относительно указателя, и целочисленное переполнение не более, чем на некоторую величину. Уязвимостей к абсолютно случайному чтению существует гораздо меньше, чем к ограниченному.

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

В течение недели PaX Team планирует выпустить плагин для GCC, который позволяет бороться c целочисленным переполнением в случаях, когда точно известно, что оно нежелательно. В частности, в случае переполнения размера буфера, передаваемого в юзерспейс посредством copy_from_user.

Вот это действительно безопасность как процесс. В течение этого года это будет уже пятый плагин.

>> Лучше, но, во-первых, лишь с недавнего времени,
> :-P

А в OpenBSD и до сих ничего не сделано, и не только это. Перемен (даже тех, которые актуальны для борьбы с продемонстрированными способами атак) можно годами ждать и не дождаться.

>> Так вот, с недавнего времени для предотвращения
>> утечек со стека PaX Team разработал плагин для GCC >= 4.5,
>> который зануляет стек сисколлов перед использованием. Правда, не целиком, а на
>> базе эвристики - иначе, оверхед слишком велик.
> Зануление лишь уменьшит окно, но не спасёт на 100%: атакующему достаточно считать

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

> значение (канарейки, или что там ещё вкусное будет) на стеке во
> время работы соответствующего системного вызова, и делать ему это в любом
> случае надо из другого потока выполнения. Так что эффективность этой меры

Обратите внимание, что постулат "в любом случае" вы никак не обосновали. Это не только не аргумент, но и слишком беспечный взгляд на возможности атакующего.

> не больше, чем у того же SSP. ;) Кстати, в документации
> PaX написано то же самое, про неполную эффективность.

Вы сравниваете эффективность меры защиты от эксплуатации линейных переполнений с эффективностью защиты от утечек - яблоки с апельсинами.

>>> А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся
>>> в том же PaX технологий?
>> Я могу сказать, что эксплуатацию через userland pointer dereference PaX останавливает на
>> 100% на x86, с высокой вероятностью на amd64 (требуется утечка памяти
>> для обхода защиты)
> Имеется в виду именно выполнение кода по указанному адресу в области данных
> пользовательского процесса, как я понимаю? Или PaX как-то отлавливает несанкционированные
> чтение-запись?

Нет, любое стандартное обращение по указателю: на чтение и запись тоже.

> А передача управления на исполняемый код пользовательского процесса? На область стека?

Предотвращается на 100% посредством KERNEXEC.

> Запрет на отображение по нулевому адресу в OpenBSD есть, и, прошу заметить,
> не отключается никакими переменными.

Я знаю, что есть, и уже говорил об этом.

>> Эксплуатацию через возврат на данные в памяти ядра, как в случае IPv6-уязвимости
>> в OpenBSD, PaX останавливает на 100%.
> На любой платформе?

На x86, amd64, 64-битных SPARK'ах и ARM - практически взеде, где есть та или иная аппаратная поддержка запрета на выполнение кода на заданных страницах/сегментах/регионах.

>> Утечки памяти при её выделении юзерспейсу - на 100%.
> Хм. Я-то думал, такое из популярных ОСей только в винде бывает (как
> сейчас - не знаю, а в WinXP и ранее память после
> TerminateProcess() утекала точно).

Утечки данных с освобождённой памяти встречаются повсеместно. А что, в OpenBSD зануляется абсолютно вся память перед выделением в юзерспейс?

> Вы меня вообще не слышите, что ли? Я говорю, что помимо ядра
> есть и другие процессы. И что защищать надо НЕ ТОЛЬКО ядро.

Я вас слышу и понимаю. Постарайтесь и вы понять.

> А вы себе, получается, противоречите: когда речь идёт о защите ядра,
> то вы возмущаетесь, когда не все меры сразу принимаются; а когда

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

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

Ничего подобного. Вы сейчас свалили в кучу защиту вообще и защиту в частности, меры предотвращения эксплуатации и меры смягчения её последствий. Разницу и границу между этими вещами я не стирал и более того: уже не единожды явно обозначил.

В первом ответе лично вам я сказал:

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

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

> За какой принцип? Что не надо думать односторонне? Вроде бы вы то
> же самое говорите. Только как-то избирательно.

Принцип разделения привилегий.

> "Масса"? Я привёл пример. Очевидный для любого человека, который умеет складывать 2

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

> и 2. А вы не то занимаетесь подтасовкой и передёргиванием (не
> хочу в это верить, но допускать такую возможность приходится), не то
> просто не видите противоречия.

Подтасовкой чего? Передёргиваете вы - именно ваши выводы не согласуются с фактами.

> Моя интерпретация базируется на сказанном. Ваша - на якобы подуманном. Разницу чуете?

Ваша интерпретация базируется на сказанном, выдранном из контекста, и противоречит фактам. Моя - согласуется с фактами и сделана на базе факта несоблюдения принципа разделения привилегий в рамках данной его конкретной реализации. Чуете разницу?

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

Вы считаете указанные противоречия ложными?

> Этот контекст не был напрямую озвучен. Было сказано (буквально!), что в разделении

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

> привилегий пользовательских приложений нет смысла, так как не бывает ядер ОС
> без изьянов. Это высказывание неверно изначально, безо всякого доведения до абсурда,
> так как оставляет за бортом класс уязвимостей, дающих root-доступ к ОС.

Кроме прочего, это высказывание не содержит определения смысла (sense), которое имеет ключевое значение. Поэтому для его буквального толкования у вас просто недостаточно фактов.

Найти наиболее близкое определение смысла в данном случае, проанализировав контекст, вы отказались. Я это сделал за вас. Вы не согласились. Я указал на противоречия вашей трактовки фактам, на что вы ничего конкретного не возразили. Я предложил вам задать вопросы автору высказывания непосредственно - вы предпочли этого не делать. И наконец, вы избирательно игнорируете контекст: значение слова "смысл" вы предпочли додумать за автора самостоятельно. Из этог я делаю вывод, что факты вас не интересуют. Тем более, что контекст вы игнор

> А если, по-вашему, автор текста хотел сказать на самом деле что-то другое,
> то почему бы он не хотел сказать что-то другое и по

А какие у вас основания полагать, будто он где-то хотел сказать что-то другое? У меня их нет (в контексте моего понимания смысла сказанного, без видимых противоречий фактам).

> другим моментам, на которые вы напираете? Путём догадок можно и чёрное
> в белое превратить.

Именно этим вы и занимаетесь. Вырвали фразу из контекста и придрались к самой буквальной трактовке - да этот приём стар, как цивилизованный мир!

> То есть по чётным дням недели он специалист по безопасности, а по
> нечётным его нельзя слушать? Гениально.

Сделать из доводов собеседника абсурдные выводы и прокомментировать их, как точку зрения собеседника - тоже старый приём. Вам полемики захотелось? А ведь "гениальный" вывод, который вы озвучили, следует из вашей же трактовки смысла обсуждаемой цитаты. Действительно, гениально. ;)

> Ещё раз: ваши доводы базируются на ваших догадках, что хотели сказать. Мои
> - на том, что было сказано. Вы сами напираете на разработчиков

Как я указал выше, ваши доводы также базируются на догадках о значении слова "смысл" (sense).

> OpenBSD, что, дескать, слова расходятся с фактами. А другим это, стало
> быть, простительно?

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

> А это уже совсем другой разговор.

Нет. Как это относиться к теме обсуждения я уже пояснил.

> то же время: http://www.openbsd.org/papers/csw03/. И если б то, к чему я,

http://www.openbsd.org/papers/ven05-deraadt/

> по-вашему, безосновательно придрался, было единственным подобным моментом... Вот это,
> например:
> "we learn that the buffer is ALWAYS at the same place. how

...
> из этой цитаты действительно крутой спец, то должен всё это понимать.

А у вас есть сомнения в том, понимает ли? Любопытно, что для человека, который так ценит буквальный смысл в словах, вы обошли вниманием капитель в слове ALWAYS. ;) Присмотритесь к слайду, о котором шла речь:

http://www.openbsd.org/papers/ven05-deraadt/mgp00005.html

> Ну или хотя бы перед тем как кидаться обвинениями, заглянуть в
> исходный код, соответствующая логика в sys/kern/kern_exec.c не менялась как минимум с
> 01.01.2003.

Какими обвинениями?

> "apparently on OpenBSD the top of the stack is what normal mortals
> consider the bottom of it".
> Видимо, товарисч не знает, что на разных аппаратных платформах стек может расти
> в разные стороны. Что, правда, вполне ожидаемо от автора x86-only (изначально)
> патча. Вот ещё одно свидетельство оторванности от реальности:

Видимо? Ах, какое смелое допущение! А как же буквальный смысл? Вы его разлюбили? ;)

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

> "and you're wondering why other vendors haven't picked it up (one wonders
> where OpenBSD picked it up from). maybe because they can count
> further than 15. what about 24, or 32 or whatever the
> address space reasonably allows? sounds better, doesn't it."
> Видимо, автор забыл, что на некоторых платформах и 256 КБайт памяти могут

256 килобайт адресного пространства? Это где, на микроконтроллерах? ;) У меня есть другая гипотеза (согласуется с фактами, почерпнутыми из других ваших сообщений): вы, возможно, забыли разницу между объёмами доступной физической памяти и адресным пространством виртуальной, на базе которого реализован ASLR.

> быть роскошью (к слову, значение этого лимита разное на разных платформах,
> на том же vax оно ещё меньше, например). Более того, в

Ох уж эта любовь к экзотике! :) Так и вижу, картина маслом: "Разработчики OpenBSD ограничивают энтропию ASLR на всех платформах по верхней границе для одной из экзотических." ;)

> предыдущем абзаце автор удосужился уточнить: "(or more precisely, whatever our admin
> deemed acceptable for his sense of security)", но, видимо, к концу
> абзаца забыл об этом.

Видимо, очевидно, само-собой разумеется! :) Забыл потому что забыл. ;)

> А вот о провидческом таланте, которым вы восхищались:

Вы стихи не пишете? А прозу? Если нет, советую. В вас пропадает талант к художественному преувеличению. :)

> "here we are told that i386 is not all that bad provided
> one uses its 64 bit cousin and learns to program in
> PAE mode. apparently the latter is a serious challenge for the
> OpenBSD Team (read: they couldn't just lift the code from FreeBSD)."
> Как я уже говорил в этой теме, PAE в OpenBSD таки появился.

Вот только забыли упомянуть, что тогда его не было. И более того:
http://www.openbsd.org/papers/ven05-deraadt/mgp00018.html ;)

> Ну и так далее...

И тому подобное! А как же иначе. ;)

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

А если не припомните, значит, их нет?

> - с кем не бывает, так и я вам скажу, что
> две уязвимости в заметно большем количестве кода - с кем не
> бывает.

Со всеми бывает. Вот только сути моих выводов и вопросов это не меняет.

> Угу. Правда, в OpenBSD все её защитные фичи есть, работают изначально и
> - прошу заметить - на всех платформах. В то время как

И что? Знаете, лично меня эти измерения не интригуют нисколько. Мне практическая сторона вопроса интересует. А на неё не влияет, что и где включено в патчах, а что по умолчанию.

> PaX в mainstream так что-то и не идёт... Тот же Hardened

И? Озвучьте же выводы. Или это такая риторика, которая должна обескуражить? :)

> Gentoo никто не отменял, согласен, но и софт не весь в
> нём работает, имеющийся в "обычном" варианте Gentoo, так ведь?

Не так. Весь софт работает. Если что-то не работает, это можно настроить без пересборки чело-либо - отключить мешающие защиты для данного конкретного бинарника. Опять же, не вижу, какое это имеет отношение к делу. Вот в OpenBSD из-за запрета на маппинги по нулевому адрему есть проблемы с некоторыми приложениями в Wine. А в PaX этот запрет можно отключить, и на защите UDEREF это никак не скажется.

> (Кстати, в ходе раскопок с удивлением узнал, что Ubuntu - по сути,
> единственный из mainstream-дистрибутивов Linux, где по умолчанию включён SSP)

Он включён практически во всех популярных дистрибутивах, короме дебиана. Просто где-то это -fstack-protector, а где-то - -fstack-protector-all.

>> Ну-ка, ну-ка!.. В свете упоминания ответственности за слова, у вас никаких претензий
>> к разработчикам OpenBSD нет, *случайно*?
> В обсуждаемом докладе была _ложь_? Упрёки в том, что в OpenBSD не

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

> было реализовано (или реализованно слабее) что-то, что уже было в PaX,
> я видел. Насмешки о (якобы) бесполезности тех или иных моментов видел.

Это где же это насмешки? :)

> Понты видел. Утверждений о лжи не видел.

Ссылку на понты покажете, или на слово вам поверить? ;)

> Да НИКТО не спорит с этим, в который раз уже говорю. Просто
> оно - не единственный процесс в системе. Защищать ядро надо? -
> надо. В первую очередь? - да.

Может быть, проясните тогда, почему безопасностью ядра в OpenBSD занялись в последнюю очередь?

> Но: следует ли игнорировать другие
> защитные механизмы и заниматься только ядром? - очевидно, нет.

Обратного я не утверждал. К чему эта полемика?

> Потому что одно не отменяет другого. Если у вас (хакера) есть два
> врага, Вася (ядро) и Петя (обычный процесс), и на Пете есть
> бронежилет, которого нет на Васе, это ещё не 100% гарантия, что
> Вася сдастся раньше Пети. Здесь можно вести речь лишь о вероятностях.

Ну, как показала практика, Петя таки сдался раньше Васи. В OpenSSH опубликовали уязвимость ещё до того, как были реализованы защиты юзерспейса и разделение привилегий (которое, кстати, на эксплуатируемость ошибок в коде практически не влияет - влияет только на его привилегии). В ядре с тех пор опубликовали 3 уязвимости, полная компрометация через две из которых предотвращается с помощью запрета на 0-маппинги.

> У меня вопросов и сомнений нет. Догадки (что было сказано) есть у

Зато у вас есть утверждения, которые, к тому же, не согласуются с фактами.

> вас. Вы утверждаете, что автор текста имел в виду не то,
> что им написано - вам это и доказывать, не?

Нет. Я утверждаю, что он имел ввиду не то, что вы решили, выдрав его фразу из контекста.

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

То есть, фразу из контекста выдрали вы, а доказывать, что не верблюд, должен я? :)

> по этому пункту. Всё равно никто никого не убедит. :)

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

> А экспертов в области безопасности по какому принципу отбирать? Как работавших над

Принципов нет. Признаки есть. Например, что является основным занятием или сколько времени уделяет человек работе над различными аспектами безопасности. Числятся ли за ним публикации, уникальные исследования или нетривиальные реализации способов защиты или нападения. Не самозванный ли он эксперт - имеет ли заслуженный авторитет в сообществе. И т.д., но этого, думаю, достаточно.

> PaX/GrSecurity или как не работавших над OpenBSD? ;)

Хехе.

> По простой: сравнить эффективность подхода к безопасности в OpenBSD и Linux спустя
> те самые восемь лет не в теории, а на фактах.

То есть, обсуждаем линукс с PaX/Grsecurity по сравнению с OpenBSD, а сравнивать вы предлагаете апстримный линукс? И противоречий в этом никаких не находите? :)

> Maintream с mainstream'ом, это "что попало"? Впрочем, жду ваших цифр. Мои цифры

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

> таковы: Для OpenBSD 4.9 (то есть полгода с момента выхода релиза)

Вашими цифрами можно хвастаться в неформальном разговоре среди фанатов ОС. А в чём и на сколько hardened-линукс уступает/превосходит OpenBSD, из них никак не следует.

> errata ПУСТАЯ. Ну, не нашлось ничего, что тянуло хотя бы на
> проблему надёжности вообще.

И какие вы делаете выводы? Озвучьте их, пожалуйста. И сразу, я уверен, станет ясно, какое отношение они имеют (и имеют ли) к обсуждаемым вовросам.

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

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

> Может, причём. А, может, и нет. Если для злоумышленника нет доступной уязвимости

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

> в ядре, ему хватит и просто рутовых прав. Поэтому источник проблем
> в виде процесса с рутовыми правами надо ТОЖЕ прикрывать.

Конечно, надо. Вопрос в том, когда и насколько это имеет смысл, а когда - нет или не особенно.

> Дважды за десять с лишним лет, да. (см. выше)

Я понимаю, почему вы ставите на этом акцент. Почему я не ставлю, можно понять, прочитав мои сообщения. Вот только ваши цифры - это уход от темы: какое из звеньев - ядро или службы в OpenBSD - слабее и подлежит усилению в первую очередь.

> Тем не менее, реализовали вовремя. "Если бы да кабы, да росли во
> рту грибы..." Вы пишете так, как будто жалеете, что разработчики OpenBSD

Во-первых, вы скачите от темы к теме. Я вам указал на то, что в OpenSSH было опубликовано меньше уязвимостей чем в ядре, хотя OpenSSH гораздо популярнее и привлекательнее ядра OpenBSD. Это ставит под сомнение вашу гипотезу о том, будто ядро является более сильным звеном, и его нужно защищать во вторую очередь.

Во-вторых, что значит, во время? Реализовали через *несколько лет* после публикации и повсеместного использования данного класса уязвимостей. А защиту от эксплуатации через возврат на страницу с данными не реализовали до сих пор.

> это сделали, и что не схлопотали ещё одну 0-day уязвимость.

Одну не схлопотали, так другую схлопотали. А уязвимость, аналогичную первой в IPv6, схлопочат и сейчас, если таковая будет опубликована.

>> Где же ваше соотношение 20/30?
> Навскидку из сделанного в ядре с того момента - улучшили рандомизацию адресного
> пространства, ужесточили контроль над памятью при вводе-выводе, добавили и, разумеется,
> начали использовать опции GCC (-Wstack-larger-than-N, -Wbounded, -Wvariable-decl; описаны
> в gcc-local(1): http://www.openbsd.org/cgi-bin/man.cgi?query=gcc-local&sekti...
> )...

Опять-таки, мы обсуждаем сравнительную защищённость ядра и сервисов. И не просто, а таковую на момент выхода презентации и её комментариев от PaX Team. Я фактически опроверг ваши аргументы, использовав метрику (количество опубликованных уязвимостей), на которую вы неоднократно ссылались сами. Есть вам, что возразить по существу?

>> Где цифры, где факты? Ещё раз: одна уязвимость в OpenSSH против двух
>> в ядре. При этом уж что-что, а OpenSSH пользуется гораздо большей
>> популярностью, чем опен - в раз, эдак... на несколько порядков -
>> и цели защищает гораздо более многочисленные и привлекательные.

Вот моя цитата ^^. А вот ваш ответ:

> Правильно, и поэтому код OpenSSH исследует больше людей, чем код ядра OpenBSD.
> Да и по объёму кода они отличаются в более чем сорок
> раз: 2,5 мегабайта против 106. Вот вам и цифры. А если
> учесть ещё и тот факт, что с возрастанием количества кода, количество
> потенциально уязвимых мест возрастает отнюдь не линейно...

Где в вашем ответе что-либо, опровергающее фактическую корректность или практическую значимость мною сказанного? Вы даже укрепили мои аргументы, указав на следующее:
- OpenSSH подвержен большему вниманию извне
- в ядре гораздо больше кода, чем в OpenSSH
- при возрастании объёмов кода количество потенциальных уязвимостей возрастает нелинено

Теперь вопрос. Считаете ли вы, что эти факты и эмпирические наблюдения опровергают мою точку зрения, а не подкрепляют её?