>> будет известно. Хреново.Можете мя закапывать - я сослепу перепутал в листинге запись константы и обращение к памяти по заданному адресу... После дополнительных проверок - таки да, канарейка выставляется случайная при запуске, общая для всех функций (системных вызовов в случае ядра). Впрочем, для её считывания всё равно надо иметь возможность читать более-менее произвольную область памяти. (см. ниже)
>> Если не стоковое, то нужна не просто утечка,
>> а из данного системного вызова. Две разных уязвимости на один системный
> Уязвимость к утечке может быть где угодно. Главное, чтобы утечка произошла с
> адреса на общем стеке, где лежит canary-значение, сохранившееся после предыдущего сисколла.
Не совсем понял фразы "общий стек": для каждого потока выполнения в ядре свой стек. Но добраться до этого стека при условии, что мы можем считывать произвольную область памяти через уязвимость в произвольном системном вызове, конечно, можно.
Другое дело, что возможность считать произвольный адрес в памяти несёт в себе столько потенциальных угроз (вроде считывания ключей IPSec), что в гроб ложиться можно сразу. Так что я бы не стал заморачиваться утаиванием канарейки, а обратил внимание в первую очередь на исходную проблему (возможности считывания), как более актульную. Тем более, что никакой дополнительный слой защиты от таких ошибок не спасёт: как он отличит легальное обращение к, скажем, контексту процесса от нелегального?
>> В вашем ненаглядном PaX, как я понимаю, дела обстоят лучше? Что там
>> генерится?
> Лучше, но, во-первых, лишь с недавнего времени,
:-P
> а во-вторых, PaX не имеет никакого отношения к SSP.
Ну, да, прошу прощения, имелось в виду что сделано касаемо отлавливания ошибок с переполнением буфера в рамках проектов PaX/GrSecurity.
> Так вот, с недавнего времени для предотвращения
> утечек со стека PaX Team разработал плагин для GCC >= 4.5,
> который зануляет стек сисколлов перед использованием. Правда, не целиком, а на
> базе эвристики - иначе, оверхед слишком велик.
Зануление лишь уменьшит окно, но не спасёт на 100%: атакующему достаточно считать значение (канарейки, или что там ещё вкусное будет) на стеке во время работы соответствующего системного вызова, и делать ему это в любом случае надо из другого потока выполнения. Так что эффективность этой меры не больше, чем у того же SSP. ;) Кстати, в документации PaX написано то же самое, про неполную эффективность.
>> А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся
>> в том же PaX технологий?
> Я могу сказать, что эксплуатацию через userland pointer dereference PaX останавливает на
> 100% на x86, с высокой вероятностью на amd64 (требуется утечка памяти
> для обхода защиты)
Имеется в виду именно выполнение кода по указанному адресу в области данных пользовательского процесса, как я понимаю? Или PaX как-то отлавливает несанкционированные чтение-запись?
А передача управления на исполняемый код пользовательского процесса? На область стека?
> а NULL pointer dereference (подкласс предыдущего класса) останавливает
> везде, благодаря обычному уже запрету на маппинги по нулевому адресу (код
> которого, кстати, давно включён в апстрим).
Запрет на отображение по нулевому адресу в OpenBSD есть, и, прошу заметить, не отключается никакими переменными.
> Эксплуатацию через возврат на данные в памяти ядра, как в случае IPv6-уязвимости
> в OpenBSD, PaX останавливает на 100%.
На любой платформе?
В случае с той IPv6-уязвимостью изначально имела место быть перезапись лишних данных из-за некорректной инициализации. Которая была отягощена наличием указателя на используемую функцию в перезаписываемой структуре (сейчас она вообще упразднена, к слову). Но и без этого указателя можно было бы натворить дел, просто сложнее.
> Утечки памяти при её выделении юзерспейсу - на 100%.
Хм. Я-то думал, такое из популярных ОСей только в винде бывает (как сейчас - не знаю, а в WinXP и ранее память после TerminateProcess() утекала точно).
>[оверквотинг удален]
> - процент назвать не берусь, но общее мнеие, что USERCOPY весьма
> эффективен в этом.
> Если коротко, то почти все уязвимости, которые были упобликованы для линукса, либо
> невозможно (не считая DoS-эффекта - тут линукс в аутсайдерах), либо значительно
> сложнее эксплуатировать на PaX-ядрах, за исключением редчайших случаев arbitrary read+write
> или более частых утечек + arbitrary write (при некотором везении).
>> Ошибка (не столько техническая - назвать страуса павлином, - сколько логическая, да)
> Логическая ошибка - это упорно назвать ядро ядром, с такой коннотацией, будто
> оно и не процесс вовсе, и защищать его нужно отдельно от
> остальных процессов и хранимых данных.
Вы меня вообще не слышите, что ли? Я говорю, что помимо ядра есть и другие процессы. И что защищать надо НЕ ТОЛЬКО ядро. А вы себе, получается, противоречите: когда речь идёт о защите ядра, то вы возмущаетесь, когда не все меры сразу принимаются; а когда этот же принцип обобщается на все процессы, то вы уже пытаетесь доказать, что этим заниматься нет смысла.
> Принцип, за который вы так уцепились, строго говоря, в ОС вроде OpenBSD,
> линукса и им подобным воплотить невозможно по определению этого самого принципа.
За какой принцип? Что не надо думать односторонне? Вроде бы вы то же самое говорите. Только как-то избирательно.
> Однако к умалчиванию такого "нюанса" у вас претензий нет, зато есть
> масса скепсиса по отношению к квалификации человека, о которой вы не
> имеете даже концептуального представления, достаточно близкого к полному.
"Масса"? Я привёл пример. Очевидный для любого человека, который умеет складывать 2 и 2. А вы не то занимаетесь подтасовкой и передёргиванием (не хочу в это верить, но допускать такую возможность приходится), не то просто не видите противоречия.
>> в том, что он прямо говорит: "разделение привилегий бесполезно, так как
>> неуязвимых ядер не бывает". Простите, но это бред. Вы сами ниже
> Вы упорно игнорируете контекст сказанного. Следуя вашей интерпретации, PaX Team считает
> бесполезным и отделение суперпользователя от обычных пользователей, и MAC-системы в части
> функций, не ограничивающих доступ к ядру, и само разделение привилегий исполняемых
> страниц памяти - чего уж там, если компрометация непривилегированного процесса равносильна
> компрометации всей системы. For noone has a bugfree kernel же.
Моя интерпретация базируется на сказанном. Ваша - на якобы подуманном. Разницу чуете?
> Где те границы, не позволяющие довести мнение компетентного человека до абсолютного абсурда?
> Вы их стёрли, цепляясь к словам и утверждая, что контекст неважен.
Этот контекст не был напрямую озвучен. Было сказано (буквально!), что в разделении привилегий пользовательских приложений нет смысла, так как не бывает ядер ОС без изьянов. Это высказывание неверно изначально, безо всякого доведения до абсурда, так как оставляет за бортом класс уязвимостей, дающих root-доступ к ОС.
А если, по-вашему, автор текста хотел сказать на самом деле что-то другое, то почему бы он не хотел сказать что-то другое и по другим моментам, на которые вы напираете? Путём догадок можно и чёрное в белое превратить.
> Фактически, следуя вашей интерпретации, PaX Team в обзоре презентации говорит одно,
> а на деле занимается соврешенно противоположным, укрепляя защиту ядра от атак
> со стороны пользовательских процессов. Всё, включая факты и здравый смысл, противоречит
> вашей гипотезе. Единственное, что можно было бы утверждать, имея хоть какие-то
> основания - это то, что PaX Team слишком резко сказал сгоряча.
> Однако, сомнений в его хладнокровии я не слышал - только сомнения
> в квалификации.
То есть по чётным дням недели он специалист по безопасности, а по нечётным его нельзя слушать? Гениально.
> Если вам этих доводов мало, мне больше возразить нечего.
Ещё раз: ваши доводы базируются на ваших догадках, что хотели сказать. Мои - на том, что было сказано. Вы сами напираете на разработчиков OpenBSD, что, дескать, слова расходятся с фактами. А другим это, стало быть, простительно?
>> пишете, что, мол, "По моей логике, реализовав разделение привилегий, нужно браться
>> за усиление ядра, или наоборот". Вот, одну вещь сделали. Ваша (или,
>> по крайней мере, товарища Альбертса) претензия в том, что это не
> Вы спутали автора перепоста на bugtraq с PaX Team aka pipacs -
> он известен только под псевдонимами.
Прошу прощения.
>> произошло одновременно? Ну извините. Может, PaX/GrSecurity тоже за ночь появились? Или
>> напомнить об уязвимостях в самих этих защитных механизмах? Я не User294
> Претезния в том, что эти риски, обусловленные незащищённым ядром, не были даже
> упомянуты (!) в обсуждаемой презентации, а меры по их снижению (механизмы
> защиты ядра) не реализованы до сих пор, спустя почти семь лет
> (!), а вовсе не одну ночь.
А это уже совсем другой разговор.
Вообще говоря, я так и не понял, про какую презентацию была речь. Полагаю, она не сильно отличалась от, например, этой, опубликованной в примерно то же время: http://www.openbsd.org/papers/csw03/. И если б то, к чему я, по-вашему, безосновательно придрался, было единственным подобным моментом... Вот это, например:
"we learn that the buffer is ALWAYS at the same place. how nice. how secure. stuff like environment strings, program arguments and whatnot surely have no role in the stack pointer value. apparently not on OpenBSD. proactive insecurity, isn't it."
Что имелось в виду, мне, честно говоря, до конца не понятно. Допущение, что буфер будет в разных местах, оно усложняет жизнь атакующему, а не облегчает. Но разбирать-то надо наихудшие _для_защищающегося_ варианты. Взять какой-нибудь системный сервис из стоковой поставки, типа того же sshd: он наверняка будет запускаться в одинаковом окружении (ну разве что локаль разная) и с одинаковыми параметрами на многих, многих машинах. Но если автор слов из этой цитаты действительно крутой спец, то должен всё это понимать. Ну или хотя бы перед тем как кидаться обвинениями, заглянуть в исходный код, соответствующая логика в 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 (изначально) патча. Вот ещё одно свидетельство оторванности от реальности:
"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 КБайт памяти могут быть роскошью (к слову, значение этого лимита разное на разных платформах, на том же vax оно ещё меньше, например). Более того, в предыдущем абзаце автор удосужился уточнить: "(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 таки появился. Ну и так далее...
> Об уязвимости - единственной - я и без вас помню.
Я просто к тому, что не могу припомнить уязвимостей, порождённых внедрением защитных технологий в OpenBSD. А если вы скажете, что, мол, одна уязвимость - с кем не бывает, так и я вам скажу, что две уязвимости в заметно большем количестве кода - с кем не бывает.
> Остальные уявзимости
> были найдены в изначальном коде ядра, и если поддавались эксплуатации, то
> в обход мер защиты PaX/Grsecurity, а не путём их отключения или
> нахождения недокументированного изъяна.
Угу. Правда, в OpenBSD все её защитные фичи есть, работают изначально и - прошу заметить - на всех платформах. В то время как PaX в mainstream так что-то и не идёт... Тот же Hardened Gentoo никто не отменял, согласен, но и софт не весь в нём работает, имеющийся в "обычном" варианте Gentoo, так ведь?
(Кстати, в ходе раскопок с удивлением узнал, что Ubuntu - по сути, единственный из mainstream-дистрибутивов Linux, где по умолчанию включён SSP)
>> и кричать epic fail по этому поводу не собираюсь, косяки у
>> всех бывают. Но как-то думать над тем, что пишешь, тоже надо.
>> Ну или отвечать за свои слова.
> Ну-ка, ну-ка!.. В свете упоминания ответственности за слова, у вас никаких претензий
> к разработчикам OpenBSD нет, *случайно*?
В обсуждаемом докладе была _ложь_? Упрёки в том, что в OpenBSD не было реализовано (или реализованно слабее) что-то, что уже было в PaX, я видел. Насмешки о (якобы) бесполезности тех или иных моментов видел. Понты видел. Утверждений о лжи не видел.
>> Я не пойму, что вы покрываете автора текста, он вам денег должен?
>> :)
> Вы, действительно, не понимаете. Как ещё объяснить, я уже не знаю -
> как донести до вас очевидное, что как сколько ядром не называй
> и из схем не исключай, оно останется большим, уязвимым, абсолютно привилегированным
> процессом с полностью открытым внешним интерфейсом.
Да НИКТО не спорит с этим, в который раз уже говорю. Просто оно - не единственный процесс в системе. Защищать ядро надо? - надо. В первую очередь? - да. Но: следует ли игнорировать другие защитные механизмы и заниматься только ядром? - очевидно, нет.
>> Спасибо, кэп.
> Ну тогда я не понимаю, почему вам не нравится, что оспаривая состоятельность
> принципа разделения привилегий, я указываю на изъяны в ядре. Совершенно не
> понимаю.
Потому что одно не отменяет другого. Если у вас (хакера) есть два врага, Вася (ядро) и Петя (обычный процесс), и на Пете есть бронежилет, которого нет на Васе, это ещё не 100% гарантия, что Вася сдастся раньше Пети. Здесь можно вести речь лишь о вероятностях.
>> Я не люблю строить догадки, кто что имел в виду. Есть конкретные
> А знаете, что? IRC-сеть OFTC, канал #pax, ник pipacs - выскажите ваши
> вопросы и сомнения непосредственно виновнику торжества непонимания. Что мы, действительно,
> догадки сторим...
>> слова: "privilege revocation does actually make sense however privilege separation (not
>> seperation) doesn't. for noone has a bugfree kernel". Если он хотел
>> сказать что-то другое - сочувствую, конечно, но подтверждений этому не вижу.
> Так сходите и найдите. Дело пяти минут. Не застанете его на канале
> - ну так держать Xchat в трее до поры тоже не
> накладнее, чем тратить время на комментарии здесь. Ага?
У меня вопросов и сомнений нет. Догадки (что было сказано) есть у вас. Вы утверждаете, что автор текста имел в виду не то, что им написано - вам это и доказывать, не?
Ну а если вы считаете, что ничего доказывать не надо, предлагаю разойтись по этому пункту. Всё равно никто никого не убедит. :)
>> Я смотрю на количество errata в ядре Linux и ядре OpenBSD, например.
> Я вам ещё одно количественное сравнение предлагаю: назвать хотя бы одного (!)
> эксперта в области безопасности, котороый бы входил в команду разработчиков OpenBSD
> или хотя бы сотрудничал с ними на более-менее постоянной основе. Это
> я кагбе намекаю на косвенное следствие из разницы в популярности двух
> ОС и "шарма" Тео и ко. в вопросах привлечения людей со
> стороны.
А экспертов в области безопасности по какому принципу отбирать? Как работавших над PaX/GrSecurity или как не работавших над OpenBSD? ;)
> Это во-первых. Но в-нулевых, я не понимаю, по какой причине вы перескочили
> на подсчёт опубликованных уязвимостей в линуксе и OpenBSD.
По простой: сравнить эффективность подхода к безопасности в OpenBSD и Linux спустя те самые восемь лет не в теории, а на фактах.
> Во-вторых, считаете уязвимости - считайте их для ядер с PaX/Grsecurity. Нет такой
> статистики? Ну, если для вас это повод сравнивать что попало... Даже
> не знаю, стоит ли возражать.
Maintream с mainstream'ом, это "что попало"? Впрочем, жду ваших цифр. Мои цифры таковы: Для OpenBSD 4.9 (то есть полгода с момента выхода релиза) errata ПУСТАЯ. Ну, не нашлось ничего, что тянуло хотя бы на проблему надёжности вообще.
>[оверквотинг удален]
> not an issue. During our ongoing auditing process we find many
> bugs, and endeavor to fix them even though exploitability is not
> proven. We fix the bug, and we move on to find
> other bugs to fix. We have fixed many simple and obvious
> careless programming errors in code and only months later discovered that
> the problems were in fact exploitable.
>> хотя честно читаю source-changes@, и разглядываю все настораживающие коммиты.
> А толку-то? Что вы там собираетесь увидеть, если даже разработчики в security.html
> написали, что не всегда различают эксплуатабельность багов - прямо как для
> вас же писали, делайте выводы! :)
Вот поэтому и разглядываю. Как разглядывал бы в любой другой ОС, которая была бы основным полем интересов. ;)
>> Какое заблуждение? Вы вообще о чём? О том, что изоляция привилегий полезна?
> О том, что принцип разделения привилегий может быть реализован как-либо в отрыве
> от обеспечения безопасности ядра.
Нужно и то, и другое. С этим-то хотя бы вы согласны?
>> Я не пойму, вы на пару с этим товарищем не понимаете,
>> против чего вообще эта защитная мера нужна, что ли? Ядро она
>> не защищает, да, ну так и доклад-то был не "защитные техники
>> ядра OpenBSD", не? Каша у вас какая-то.
> А что, ядро в системе своей жизнью живёт? И в случае компрометации
> непривилегированного процесса вообще ни при чём?
Может, причём. А, может, и нет. Если для злоумышленника нет доступной уязвимости в ядре, ему хватит и просто рутовых прав. Поэтому источник проблем в виде процесса с рутовыми правами надо ТОЖЕ прикрывать.
>[оверквотинг удален]
>> Да, но РАЗНЫЕ звенья. Вот вам цепь, пять звеньев. Первое, второе и
>> третье держат до 50 ньютонов, четвёртое до 30, пятое до 20.
>> Усилили пятое, теперь оно тоже держит 50 ньютонов. Вопль со стороны:
>> "да нафига делали, всё равно порвётся". Цена этому воплю знаете, какая?
> А где эти намерения поработать над четвёртым? Я даже не спрашиваю, где
> они в презентации - ответьте, где они в принципе декларированы? Где,
> мать жеж перемать, хотя бы место этому звену в модели угроз
> и их противодействия? Ну усилили они пятое звено много лет назад,
> ТОЛКУ ТО?
> Пришли же потом люди и взломали ядро дважды (включая локальную уязвимость).
Дважды за десять с лишним лет, да. (см. выше)
> А не реализуй, наконец-то, разработчики запрета на маппинги по нулевому адресу (с
> многолетним опозданием после PaX/Grsecurity), уязвимости было бы три - это всё
> есть в вашей любимой эррате.
Тем не менее, реализовали вовремя. "Если бы да кабы, да росли во рту грибы..." Вы пишете так, как будто жалеете, что разработчики OpenBSD это сделали, и что не схлопотали ещё одну 0-day уязвимость.
> Где же ваше соотношение 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... )...
> Где цифры, где факты? Ещё раз: одна уязвимость в OpenSSH против двух
> в ядре. При этом уж что-что, а OpenSSH пользуется гораздо большей
> популярностью, чем опен - в раз, эдак... на несколько порядков -
> и цели защищает гораздо более многочисленные и привлекательные.
Правильно, и поэтому код OpenSSH исследует больше людей, чем код ядра OpenBSD. Да и по объёму кода они отличаются в более чем сорок раз: 2,5 мегабайта против 106. Вот вам и цифры. А если учесть ещё и тот факт, что с возрастанием количества кода, количество потенциально уязвимых мест возрастает отнюдь не линейно...
