>[оверквотинг удален]
>>>> надёжные, им можно верить. ;)
>>> А если без сарказма? И главное - если такой вот централизованный список
>> Да я уже устал повторять. И не я один. В IRC эта
>> тема за последние несколько лет поднималась на разных каналах не один
>> десяток раз. В листах рассылки, вроде, тоже проскакивало. И все, кто
>> думал своей головой и не затыкал уши, выводы давно сделали.
>> Суть в том, что разработчики OpenBSD отказались изучать возможности эксплуатации уязвимости
>> в коде IPv6 и объявили её DoS-уязвимостью. После чего Core Security
>> представила рабочий PoC-эксплойт.
> http://marc.info/?l=openbsd-misc&m=117404837006368&w=2http://pwnies.com/archive/2007/winners/#lamestvendor
http://www.coresecurity.com/content/open-bsd-advisorie
> Ошибкой OpenBSD-шников было в первую очередь то, что они доверились (скороспешному) анализу
> ребят из Core Security. То, что это возможность для удалённого выполнения
:))) Бедные, наивные - доверились! :) Если сходить по вашей же ссылке, из обтекаемого описания, составленного Тео (обратите внимание, как смещены акценты в сравнении с таймлайном на сайте Core Security), становится ясно, что у Core были опасения на счёт эксплуатабельности уязвимости, но ребята из OpenBSD их проигнорировали. Видимо, к понижению оценки опасности без оснований их тоже ребатя из Core склонили - наивных, таких, разработчиков "самой безопасной ОС в мире". ;)
> кода, выяснилось позднее. У Core Security на это выяснение ушла неделя.
> Да, они молодцы, что докопались до самого конца. Но представление разработчиков
> OpenBSD как игнорирующих проблему - это уже, мягко говоря, перебор.
Это ровно то, что произошло. Проблема не в самой уязвимости и не в том, в какие сроки она была закрыта, а в неадекватной оценке этой уязвимости и в выпуске уведомления класса RELIABILITY FIX. И это при том, что ребята из Core свои опасения высказали сразу.
Хинт: правильным поведением в этой ситуации был бы выпуск SECURITY FIX'а с пояснением, что существует вероятность выполнения произвольного кода. И вот затем, если бы такая вероятность была на 100% опровергнута, можно было б продаунгрейдить статус уведомления до RELIABILITY FIX. А не наоборот.
> По поводу игнорирования см. выше.
О сроках выхода исправления я и без вас был в курсе. Специально для вас переформулирую в части игнорирования: где гарантия, что разработчики OpenBSD не проигнорируют потенциальную возможность эксплуатации уязвимости и не дезинформируют сообщество и меня, в том числе, о степени важности исправления? Отдельно подчеркну, что уязвимость была удалённая, и недооценивать такую уязвимость - это, с моей точки зрения, недопустимо "вдвойне".
> Насчёт W^X в ядре, полноценного, насколько знаю, нет. Однако записать в область
> ядра процесс не может изначально, только само ядро может "ошибиться" и
Очень правильно вы взяли в кавычки. Именно так проводится подавляющее большинство атак на ядра - им помогают "ошибиться". ;)
> перезаписать собственный код. Учитывая, что страницы кода и данных не смежные,
В каком смысле не смежные? Границы сегментов на x86 одинаковые, а в amd64 и сегментов-то нет - одна страничная логика. Вы хотите сказать, что страницы стеков и данных в ядре OpenBSD теперь неисполняемые по умолчанию? Вам это кто-то подтвердил?
> нужно подсунуть в какой-то функции ядра вместо указателя на выделенную для
> данных область памяти - указатель на область кода ядра. Как это
> сделать, не имея уже исполнения собственного кода в ядре либо возможности
> перезаписать код (т.е., выполненной задачи), я пока что-то не представляю.
Вы всё смешали и упростили. Всё не так. И тот факт, что вы не представляете, как подсунуть - он о чём мне должен сказать? И как мне нужно реагировать на это - особенно в свете ваших комментариев о чьей-то квалификации? Как минимум через указание индекса массива на элемент за его границами и адресная арифметика на указателях позволяют обратиться к произвольной (или условно и достаточно произвольной) области памяти, не перезаписывая указатель непосредственно. Ну и способы эксплуатации внедрением кода не исчерпываются. Представьте, что будет, если всего-то нолик в какой-нибудь process->ps_cred->p_ruid "какого-нибудь" процесса записать.
>> Где документация для проведения peer review с описанием принципов и путей
>> их реализации?
> Вы повторяетесь. :)
Вы заметили!!!111 Я в шоке!!!11
Если оставить по два восклицательных знака, в этом даже не будет сарказма.
> Гм. А какие вам нужны комментарии к этому?
> Или почему этот комментарий не детальный?
Нет комментариев, достаточно полных, чтобы заменить документацию. А самодокументированный код не может заменить документацию даже в принципе - он даёт преставление о том, что делается, а не о том, что должно быть сделано и *почему*. Сами ребята из OpenBSD предпочитают писать дрова по спецификациям, а как доходит дело до стороннего анализа их творений - что? Двойные стандарты: теперь код - это спецификация? Пример с CARP я уже приводил - спецификации на протокол нет, а протокол есть.
>> Вы как хотите, а я таким экспертам доверять не стану.
> Ваше право.
Именно. И вас переубеждать сверх разумного не стану.
> Список с галочками (общий, не только по безопасности) раньше был, прямо на
> сайте. Толку от него было только чуть, никто не рвался в
> бой. Ну и убрали, ибо лучше без списка, чем с неактуальным.
> Правда, как источник информации для ревью он не расценивался.
Как, оказывается, сложно разработчикам поддерживать документацию в актуальном состоянии!
> А насчёт документации - давайте оформим ваше претензию серьёзно. Что, зачем и
> как должно быть. Если возможно, с примерами. А то язвить-то много
> ума не надо, но это как-то не конструктивно. :)
У вас есть пища для размышлений. Хотите - оформляйте. А я не смогу использовать OpenBSD в работе, даже если вдруг захочу - не подходит по ряду показателей. К тому же, я догадываюсь, что ответит Тео и остальные. ;) Вы, уверен, тоже. ;)
