В списке рассылки разработчиков OpenBSD опубликован (https://marc.info/?l=openbsd-tech&m=146159002802803&w=2) набор патчей с реализацией новой техники защиты anti-ROP, основанной на случайном перестроении порядка расположения экспортируемых символов в системной библиотеке libc.so, выполняемом при каждой загрузке системы. Перестроение приводит к увеличению времени загрузки примерно на секунду.Метод заключается в сохранении всех образующих libc файлов .so в отдельном архиве с построением нового файла libc.so при каждой загрузке, каждый раз комбинируя составные части libc.so в случайном порядке. Предложенная техника затрудняет создание ROP-эксплоитов (https://ru.wikipedia.org/wiki/%D0%92%D0%... так как составляющие эксплоит "гаджеты" меняют свои смещения при каждой загрузке, что требует создания индивидуального эксплоита для текущего состояния системы, без возможности применения эксплоитов, универсальных для типовых сборок.
URL: http://undeadly.org/cgi?action=article&sid=20160425145953
Новость: https://www.opennet.ru/opennews/art.shtml?num=44320
>основанной на случайном перестроении порядка расположения экспортируемых символов в системной библиотекеЗвучит нелепо. Нужно бороться с возможностью злоумышленника играться со стеком вызовов, а не делать "мелкие подлости" ценой довольно странных манипуляций с библиотеками.
Шнайера забыли спросить
Вы бы предложили ещё с фоннеймановской архитектуры переползти на что-нибудь другое ("гарвард" etc). Безопасно, чо!
Вы будете удивлены, но большинство современных процессоров построено как раз на Гарвардской архитектуре, правда "модифицированной". Например, ARM или x86 выполняют инструкции в кэше чисто "по-гарвардски", а манипулируют данными "по-фоннеймановски".
proof or GTFO. И как эти "модификации под гарварда" делают их "ближе к гарварду"?
Видимо, из-за умелых "модификаций" существуют разного рода, успешности, удобства hardened* проекты.
"A modified Harvard architecture machine is very much like a Harvard architecture machine, but it relaxes the strict separation between instruction and data while still letting the CPU concurrently access two (or more) memory buses. The most common modification includes separate instruction and data caches backed by a common address space. While the CPU executes from cache, it acts as a pure Harvard machine. When accessing backing memory, it acts like a von Neumann machine (where code can be moved around like data, which is a powerful technique). This modification is widespread in modern processors, such as the ARM architecture and x86 processors. It is sometimes loosely called a Harvard architecture, overlooking the fact that it is actually "modified"." (https://en.wikipedia.org/wiki/Harvard_architecture)
NX-bit и название "Modified Harvard architecture". Однако ж принцип остался тот же - процу абсолютно наплевать что вы ему суёте, код или данные, он в любом случае их попытается выполнить (за исключением областей, помеченных NX).Если серьёзно, то современные процы мало относятся и к той и к этой архитектурам. Сами архитектуры - "сферические кони в вакууме", в реальной жизни сложно разделить мир на белое и чёрное, на "гарвард" и "фон нейман". Возвращаясь именно к процессорам - им присущи как отдельные преимущества, так и недостатки обоих архитектур. За счёт программно-аппаратного разделения памяти на области кода и данных, x86, x86_64, ARM являются процессорами на базе "модифицированной гарвардской архитектуры", но только при условии если наличиствует поддержка со стороны ОС. Воткнём DOS'Ъ и новенький Intel/AMD станет привычной "фоннеймановской" машиной (реализация, конечно, будет отличаться от классической теории). Грань тонка, а железка, сама по себе, код и данные не разделяет.
Интересно посмотреть на живые экземпляры "классического" гарварда и как организована их "кухня".
>[оверквотинг удален]
> этой архитектурам. Сами архитектуры - "сферические кони в вакууме", в реальной
> жизни сложно разделить мир на белое и чёрное, на "гарвард" и
> "фон нейман". Возвращаясь именно к процессорам - им присущи как отдельные
> преимущества, так и недостатки обоих архитектур. За счёт программно-аппаратного разделения
> памяти на области кода и данных, x86, x86_64, ARM являются процессорами
> на базе "модифицированной гарвардской архитектуры", но только при условии если наличиствует
> поддержка со стороны ОС. Воткнём DOS'Ъ и новенький Intel/AMD станет привычной
> "фоннеймановской" машиной (реализация, конечно, будет отличаться от классической теории).
> Грань тонка, а железка, сама по себе, код и данные не
> разделяет.Вот с этим, пожалуй, соглашусь.
> Интересно посмотреть на живые экземпляры "классического" гарварда и как организована их
> "кухня".AVR. Там для обращения к данным в пространстве кода есть специальная инструкция, и в сишной библиотеке присутствует дополнительный набор функций, например, для сравнения строк в пространстве кода - strcmp_P, и т.п.
"мелкие подлости" в опёнке называются хаки, запишинезабудь
Это как? Провести аудит всего софта запускаемого на опенбзд? Ооок
Силами полутора разработчиков OpenBSD, которых в этом мире реально беспокоит безопасность :)
> Это как? Провести аудит всего софта запускаемого на опенбзд? ОоокВ OpenBSD аудит всей системы по тому или иному поводу — обычное дело.
defense in depth
Если у вас есть способ позволяющий побороть возможность злоумышленника играться со стеком вызовов, и если этот ваш способ работает на 100%, то есть он реально позволяет избавится от этих проблем, то я не понимаю, почему этот способ до сих пор существует только в вашем воображении, и почему ROP-атаки до сих пор актуальны.
Если же такого способа у вас нет, если ваш способ работает в 90% случаев, то он замечательно может быть дополнен мелкими пакостями, которые сработают в 90% случаев. И суммарный способ будет работать в 99% случаев.
> Звучит нелепо. Нужно бороться с возможностью злоумышленника играться со стеком вызовов,
> а не делать "мелкие подлости" ценой довольно странных манипуляций с библиотеками.Затрудняющие атаку падчи есть и давно ,для параноиков даже дистрибутивы выпускают .
Например PaX,Stack-Smashing Protector,StackGuard .
С возможностью выбора падчей и включением ролевых и других систем безопасности развивается ответвление от генты -Hardened Gentoo .Наиболее универсальный набор с интегрированными падчами у них называется grsecurity.Это софтовые методы .Но развиваются и аппаратные методы .
В 2015 году Интел добавила аппаратную защиту для стека, но к сожалению софт нужно переписывать для безопасных вызовов .В свежих Спарках появился аппаратный контроль памяти и стека ,там сетуация с софтом полегче ,т.к с самого начала на страницы и стек можно было выставлять атрибуты защиты .Печально знаменитый наш Эльбрус ,тоже есть возможность выставлять аппаратные атрибуты защиты на стэк и память ,с контекстной системой защиты .
>> Звучит нелепо. Нужно бороться с возможностью злоумышленника играться со стеком вызовов,
>> а не делать "мелкие подлости" ценой довольно странных манипуляций с библиотеками.
> Затрудняющие атаку падчи есть и давно ,для параноиков даже дистрибутивы выпускают .
> Например PaX,Stack-Smashing Protector,StackGuard .За пределами Linux тоже есть жизнь. Да-да!
Полиморфные операционные системы, дожили.
Ждем стеганографию, когда ОС будет прятаться среди прона пользователя.
> Ждем стеганографию, когда ОС будет прятаться среди прона пользователя.Вызовы API ядра по скану паспорта, заверенному gpg ключом пользователя и нотариуса! ...и шифрованные-подписанные адреса возврата в стеке -- обязательно.
Ежели паспорта, то подписанное при помощи домен-к и никак иначе.
> Ежели паспорта, то подписанное при помощи домен-к и никак иначе.С мастер-подписью первого отдела, либо заменяющих уполномоченных кураторов - заведующей школы, востпитательницы детсада и т.д.
>> Ежели паспорта, то подписанное при помощи домен-к и никак иначе.
> С мастер-подписью первого отдела, либо заменяющих уполномоченных кураторов - заведующей
> школы, востпитательницы детсада и т.д.Первого или всё же второго?
> Полиморфные операционные системы, дожили.Несимметричный ответ GNU https://www.gnu.org/software/guix/manual/html_node/Applicati... Guix-а патчетелям бинарных libc.so: _пользователь_ может каждому приложению поставить (и собрать:)) по отдельной версии GNU libc. _Каждый_ пользователь в системе -- каждое приложение со своей отдельной glibc! Смерть крацкерам.
>> Полиморфные операционные системы, дожили.
> Несимметричный ответ GNU https://www.gnu.org/software/guix/manual/html_node/Applicati...
> Guix-а патчетелям бинарных libc.so: _пользователь_ может каждому приложению поставить
> (и собрать:)) по отдельной версии GNU libc. _Каждый_ пользователь в системе
> -- каждое приложение со своей отдельной glibc! Смерть крацкерам.Раньше такое называлось^Wделалось статической линковкой... Такая идея тоже рассматривалась, но Тео относится к ней скептически.
Эволюция на планете зародилась в следствии многократного сталкивания и перестраивания случайных элементов...
>каждый раз комбинируя составные части libc.so в случайном порядкеskynet близко, покайтесь!
Судя по коментам, теоретики и практики - вещи не совместимые.
> Судя по коментам, теоретики и практики - вещи не совместимые.Это как конфликт ученых с инженерами. Разные социальные группы, мыслят по-разному.
Интересно, это потом на отладке никак не скажется? Типа, приложение упало в корку. Что оно вызвало из glibc на предыдущей загрузке системы? А фиг его знает...В корку же код библиотек, вроде, не дампается?
glibc != libc.или у вас GNU головного мозга ?
а что, бздешная либси не поддается отладке?
бздешная либси не вызывает ничего из glibc
> Интересно, это потом на отладке никак не скажется? Типа, приложение упало в
> корку. Что оно вызвало из glibc на предыдущей загрузке системы? А
> фиг его знает...
> В корку же код библиотек, вроде, не дампается?Как минимум пока не перегрузился - можно работать с дампом. Uptime на подобной системе может быть очень длительным.
Если сервер перегружали 1 раз за 10 лет не каких там трудностей.
Только ты забываешь о массовом эксплуатировании, которое становится труднее потому, что рандомизация на всех машинах разная. Многолетние аптаймы какой-то погоды тут не делают.
И все 10 лет придётся отгадывать где искать нужные функции в этой конкретной libc.
Смысл в том, что оно получается уникальным и одноразовым, а атакующий полагается на то, что заранее знает где какие кусочки кода в памяти есть.
Ну тогда можно это делать 1 раз при установке ОС.
После загрузки - это минимально доступное время между рандомизациями в BSD.
Если бы Тэо мог, он бы сделал раз в хх минут.Чем чаще оно рандомизируется - тем ниже вероятность что успеет утечь.
> После загрузки - это минимально доступное время между рандомизациями в BSD.
> Если бы Тэо мог, он бы сделал раз в хх минут.Сделать-то можно. Только тогда в каждой программе может получиться своя libc. Если даже отбросить производительность — как вы будете отлаживаться?
1 раз предполагает хранение стейта между загрузками на диске
Даже на дэсктопах, где опёнок не распространён, ось перегружают всё меньше и меньше. А на серверах тем более. Странная фича.
йоу! кто ты, что ты сделал для антиропа в свои годы! йоу-йоу.не "вызовет увеличение времени загрузки примерно на секунду", а на "самой медленной машине, какую смогли найти, это заняло секунду при загрузке"
Sony очень обрадуется таким наработкам, сразу утащат в свой Orbis OS не глядя :)
https://cturt.github.io/ps4.html
>Перестроение приводит к увеличению времени загрузки примерно на секунду.виндусодети с системдоса корчат рожи и хихикают
>>Перестроение приводит к увеличению времени загрузки примерно на секунду.
> виндусодети с системдоса корчат рожи и хихикаютИм это неактуально - проприетарный блоб для проца и видюхи обнулит все танцы безопасности с libc.
> Им это неактуально - проприетарный блоб для проца и видюхи обнулит все
> танцы безопасности с libc.Management Engine с неустранимым блобом есть с 2010 года во всех системах с процессорами Intel. Всех, Карл!
по-моему ASLR будет проще и быстрее. при где-то таком-же уровне защиты там не нужно ничего писать на диск при каждой загрузке
> по-моему ASLR будет проще и быстрее. при где-то таком-же уровне защиты там
> не нужно ничего писать на диск при каждой загрузкеНу дык, это же дополнение – ASLR всю либу целиком перемещает и, чисто теоретически, если удасться узнать один адрес, то можно будет посчитать остальные, а сабж вроде как усложнит.
Как по мне, то немного отдает паранойей … *пожимает плечами* но, никто ведь принудительно пользоваться не заставляет! А там, после/во время обкатки может быть еще пара идей появится – и глядишь, что-нибудь для более "широкой публики" выйдет.
https://grsecurity.net/rap_announce.php - тихо и незаметно...
> https://grsecurity.net/rap_announce.php - тихо и незаметно...The demo version will evolve over time, but is currently tailored for x64 kernel use only and does not support C++, link-time optimization, compile time static analysis, and probabilistic return address protection. In addition, the demo's GPLv2 license excludes userland applications due to the GCC library runtime exception for GCC plugins.
> https://grsecurity.net/rap_announce.php
History
StackGuard 1999 (XOR canary)
[...]
Response
: encrypt/decrypt return address by a random keyНадо завязывать https://www.opennet.ru/openforum/vsluhforumID3/107700.html#19 с шуточками.
...и шифрованные-подписанные адреса возврата в стеке -- обязательно.
Не смешно и уже нцать лет как продаётся -- вот и коллегами по форуму.> - тихо и незаметно...
https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf - для ознакомления. Также помогает при высоких уровнях ЧСВ головного мозга.
>/PaXTeam-H2HC15-RAP-RIP-ROP.pdf - для ознакомления.
> Также помогает при высоких уровнях ЧСВ головного мозга.Вам помогло? -- запостить pdf-ку, ссылка на которую есть суть предыдущей ссылки в посте выше?
Вы оказываете гуманитарную помощь специалистам по безопасности. прокачивающих чсв, и не владеющих ссылко-тынцаньем? Человечище!
Просто у меня сложилось впечатление, что вы, господин специалист по безопасности, в первый раз по диагонали прочли, пропустив все незнакомые слова. Тут не грех и дважды повторить. Ведь защита адресов возврата - лишь один из механизмов (не самый сложный и не самый сильный), который в текущую общедоступную версию grsec-патча даже и не включен из коммерческих соображений.