> будет известно. Хреново. Если не стоковое, то нужна не просто утечка,
> а из данного системного вызова. Две разных уязвимости на один системный Уязвимость к утечке может быть где угодно. Главное, чтобы утечка произошла с адреса на общем стеке, где лежит canary-значение, сохранившееся после предыдущего сисколла.
> вызов - гм-м-м... Теоретически возможно, конечно. Но учитывая, что между вызывающим
> потоком выполнения и собственно кодом обработчика системного вызова стоит диспетчер, я
> слабо представляю себе способ добраться до нужного системного вызова.
И теоретически, и практически. Вы слишком быстро всё списываете со счетов. Skilled attacker уж точно так не поступит, а упрётся до последнего, если компрометация системы это окупит.
> В вашем ненаглядном PaX, как я понимаю, дела обстоят лучше? Что там
> генерится?
Лучше, но, во-первых, лишь с недавнего времени, а во-вторых, PaX не имеет никакого отношения к SSP. Так вот, с недавнего времени для предотвращения утечек со стека PaX Team разработал плагин для GCC >= 4.5, который зануляет стек сисколлов перед использованием. Правда, не целиком, а на базе эвристики - иначе, оверхед слишком велик.
> А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся
> в том же PaX технологий?
Я могу сказать, что эксплуатацию через userland pointer dereference PaX останавливает на 100% на x86, с высокой вероятностью на amd64 (требуется утечка памяти для обхода защиты), а NULL pointer dereference (подкласс предыдущего класса) останавливает везде, благодаря обычному уже запрету на маппинги по нулевому адресу (код которого, кстати, давно включён в апстрим).
Эксплуатацию через возврат на данные в памяти ядра, как в случае IPv6-уязвимости в OpenBSD, PaX останавливает на 100%. Утечки памяти при её выделении юзерспейсу - на 100%. Переполнения буферов в динамической памяти при copy_from_user - процент назвать не берусь, но общее мнеие, что USERCOPY весьма эффективен в этом.
Если коротко, то почти все уязвимости, которые были упобликованы для линукса, либо невозможно (не считая DoS-эффекта - тут линукс в аутсайдерах), либо значительно сложнее эксплуатировать на PaX-ядрах, за исключением редчайших случаев arbitrary read+write или более частых утечек + arbitrary write (при некотором везении).
> Ошибка (не столько техническая - назвать страуса павлином, - сколько логическая, да)
Логическая ошибка - это упорно назвать ядро ядром, с такой коннотацией, будто оно и не процесс вовсе, и защищать его нужно отдельно от остальных процессов и хранимых данных.
Принцип, за который вы так уцепились, строго говоря, в ОС вроде OpenBSD, линукса и им подобным воплотить невозможно по определению этого самого принципа. Однако к умалчиванию такого "нюанса" у вас претензий нет, зато есть масса скепсиса по отношению к квалификации человека, о которой вы не имеете даже концептуального представления, достаточно близкого к полному.
> в том, что он прямо говорит: "разделение привилегий бесполезно, так как
> неуязвимых ядер не бывает". Простите, но это бред. Вы сами ниже
Вы упорно игнорируете контекст сказанного. Следуя вашей интерпретации, PaX Team считает бесполезным и отделение суперпользователя от обычных пользователей, и MAC-системы в части функций, не ограничивающих доступ к ядру, и само разделение привилегий исполняемых страниц памяти - чего уж там, если компрометация непривилегированного процесса равносильна компрометации всей системы. For noone has a bugfree kernel же.
Где те границы, не позволяющие довести мнение компетентного человека до абсолютного абсурда? Вы их стёрли, цепляясь к словам и утверждая, что контекст неважен. Фактически, следуя вашей интерпретации, PaX Team в обзоре презентации говорит одно, а на деле занимается соврешенно противоположным, укрепляя защиту ядра от атак со стороны пользовательских процессов. Всё, включая факты и здравый смысл, противоречит вашей гипотезе. Единственное, что можно было бы утверждать, имея хоть какие-то основания - это то, что PaX Team слишком резко сказал сгоряча. Однако, сомнений в его хладнокровии я не слышал - только сомнения в квалификации.
Если вам этих доводов мало, мне больше возразить нечего.
> пишете, что, мол, "По моей логике, реализовав разделение привилегий, нужно браться
> за усиление ядра, или наоборот". Вот, одну вещь сделали. Ваша (или,
> по крайней мере, товарища Альбертса) претензия в том, что это не
Вы спутали автора перепоста на bugtraq с PaX Team aka pipacs - он известен только под псевдонимами.
> произошло одновременно? Ну извините. Может, PaX/GrSecurity тоже за ночь появились? Или
> напомнить об уязвимостях в самих этих защитных механизмах? Я не User294
Претезния в том, что эти риски, обусловленные незащищённым ядром, не были даже упомянуты (!) в обсуждаемой презентации, а меры по их снижению (механизмы защиты ядра) не реализованы до сих пор, спустя почти семь лет (!), а вовсе не одну ночь.
Об уязвимости - единственной - я и без вас помню. Остальные уявзимости были найдены в изначальном коде ядра, и если поддавались эксплуатации, то в обход мер защиты PaX/Grsecurity, а не путём их отключения или нахождения недокументированного изъяна.
> и кричать epic fail по этому поводу не собираюсь, косяки у
> всех бывают. Но как-то думать над тем, что пишешь, тоже надо.
> Ну или отвечать за свои слова.
Ну-ка, ну-ка!.. В свете упоминания ответственности за слова, у вас никаких претензий к разработчикам OpenBSD нет, *случайно*?
> Я не пойму, что вы покрываете автора текста, он вам денег должен?
> :)
Вы, действительно, не понимаете. Как ещё объяснить, я уже не знаю - как донести до вас очевидное, что как сколько ядром не называй и из схем не исключай, оно останется большим, уязвимым, абсолютно привилегированным процессом с полностью открытым внешним интерфейсом.
> Спасибо, кэп.
Ну тогда я не понимаю, почему вам не нравится, что оспаривая состоятельность принципа разделения привилегий, я указываю на изъяны в ядре. Совершенно не понимаю.
> Я не люблю строить догадки, кто что имел в виду. Есть конкретные
А знаете, что? 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 или хотя бы сотрудничал с ними на более-менее постоянной основе. Это я кагбе намекаю на косвенное следствие из разницы в популярности двух ОС и "шарма" Тео и ко. в вопросах привлечения людей со стороны.
Это во-первых. Но в-нулевых, я не понимаю, по какой причине вы перескочили на подсчёт опубликованных уязвимостей в линуксе и OpenBSD.
Во-вторых, считаете уязвимости - считайте их для ядер с PaX/Grsecurity. Нет такой статистики? Ну, если для вас это повод сравнивать что попало... Даже не знаю, стоит ли возражать.
> В OpenBSD оно с каждым годом стремительно уменьшается. Вы, конечно, можете
> крикнуть: "потому что скрывают!". Но я пока не видел этому подтверждений,
Кстати, да. Скрывают. Но ненамеренно - в рамках обычного процесса исправления ошибок в коде. Об этом вы даже можете прочитать здесь: http://www.openbsd.org/security.html
In most cases we have found that the determination of exploitability is 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.
В линуксе, кстати, тоже скрывают - и намеренно. Отвратительная практика! Не знаю, может быть, вы уже записали меня в пингвинопоклонники, но будь полный аналог PaX в какой-нибудь Net/FreeBSD, я перешёл бы на неё с искренней радостью. Благо, в функциональность и скорость работы этих ОС для решения моих задач меня вполне устраивают (в отличие, к сожалению, от опёнка).
> хотя честно читаю source-changes@, и разглядываю все настораживающие коммиты.
А толку-то? Что вы там собираетесь увидеть, если даже разработчики в security.html написали, что не всегда различают эксплуатабельность багов - прямо как для вас же писали, делайте выводы! :)
> Какое заблуждение? Вы вообще о чём? О том, что изоляция привилегий полезна?
О том, что принцип разделения привилегий может быть реализован как-либо в отрыве от обеспечения безопасности ядра.
> Я не пойму, вы на пару с этим товарищем не понимаете,
> против чего вообще эта защитная мера нужна, что ли? Ядро она
> не защищает, да, ну так и доклад-то был не "защитные техники
> ядра OpenBSD", не? Каша у вас какая-то.
А что, ядро в системе своей жизнью живёт? И в случае компрометации непривилегированного процесса вообще ни при чём?
>> По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или
>> наоборот.
> Это ортогональные вещи, почему г-н Альбертс сплёл их вместе - только ему
> и известно.
Это звенья одной цепи. Одной! Не разные уровни защиты, понимаете? Вот меры предотвращения экслпуатации и меры смягчения последствий эксплуатации - вещи действительно ортогональные.
>> Не вижу. Обсуждаем звенья одной цепи.
> Да, но РАЗНЫЕ звенья. Вот вам цепь, пять звеньев. Первое, второе и
> третье держат до 50 ньютонов, четвёртое до 30, пятое до 20.
> Усилили пятое, теперь оно тоже держит 50 ньютонов. Вопль со стороны:
> "да нафига делали, всё равно порвётся". Цена этому воплю знаете, какая?
А где эти намерения поработать над четвёртым? Я даже не спрашиваю, где они в презентации - ответьте, где они в принципе декларированы? Где, мать жеж перемать, хотя бы место этому звену в модели угроз и их противодействия? Ну усилили они пятое звено много лет назад, ТОЛКУ ТО?
Пришли же потом люди и взломали ядро дважды (включая локальную уязвимость). А не реализуй, наконец-то, разработчики запрета на маппинги по нулевому адресу (с многолетним опозданием после PaX/Grsecurity), уязвимости было бы три - это всё есть в вашей любимой эррате. Где же ваше соотношение 20/30? Где цифры, где факты? Ещё раз: одна уязвимость в OpenSSH против двух в ядре. При этом уж что-что, а OpenSSH пользуется гораздо большей популярностью, чем опен - в раз, эдак... на несколько порядков - и цели защищает гораздо более многочисленные и привлекательные.
>> Этот "софизм" совпадает с моими собственными выводами.
> Печально.
Не это печально, поверьте мне...
