The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

07.06.2018 09:05  В состав OpenBSD-Current добавлен механизм защиты RETGUARD

В состав компилятора Clang, используемого для сборки базовой системы OpenBSD, интегрирован механизм защиты RETGUARD, нацеленный на усложнение выполнения эксплоитов, построенных с использованием заимствования кусков кода и приёмов возвратно-ориентированного программирования (ROP, Return-Oriented Programming). Механизм включен только при сборке для архитектуры AMD64.

Суть метода защиты RETGUARD заключается в искажении адреса возврата обработчиков функций. Перед началом обработчика функции добавляется вызов XOR, комбинирующий адрес возврата с генерируемым для каждой функции случайным значением Cookie, которое затем сохраняется в стек. Перед командой возврата управления из функции (ret) значение Cookie извлекается из стека и при помощи операции XOR повторно применяется к адресу возврата, что восстанавливает его исходное значение и позволяет убедиться в том, что адрес перехода не изменился. Для усложнения атак код проверки дополнительно снабжается добавочным заполнением в виде инструкций int03 перед каждой инструкцией ret.

При штатном ходе выполнения изначальный адрес перехода остаётся неизменен, но при выполнении эксплоита осуществляется переход на составляющий эксплоит блок заимствованных машинных инструкций (гаджет), точка входа в который как правило не совпадает с началом функции. Так как управление передано не на начало, а в определённую часть тела функции, первый "xor" будет пропущен и "xor" перед выходом исказит переданный эксплоитом адрес возврата. При защите функций ядра RETGUARD оценивается как эффективный для блокирования 50% из всех ROP-гаджетов и 15% уникальных гаджетов, по сравнению с ядром OpenBSD 6.3.

Метод реализован в виде патча к компилятору clang, который на этапе компиляции производит автоматическую подстановку кода проверки адреса возврата во все функции. Для функций системной библиотеки и ядра, написанных на языке ассемблер, требуется применение отдельных патчей. Для активации нового метода защиты в приложениях не требуется отдельных действий, достаточно пересобрать их предлагаемым в базовой системе OpenBSD-Current компилятором Clang, в который уже включены все необходимые патчи. Для отключения сборки с RETGUARD в Clang добавлена опция "-fno-ret-protector".

Напомним, что техника заимствования кусков кода используется для эксплуатации переполнений буфера в условиях, когда в страницах памяти стека и буфера установлен запрет на исполнение кода. Для организации выполнения кода атакующего в таких условиях логика выполнения shell-кода формируется с использованием методов возвратно-ориентированного программирования (ROP) - атакующий не пытается разместить свой код в памяти, а оперирует уже имеющимися в загруженных библиотеках кусками машинных инструкций, завершающихся инструкцией возврата управления (как правило, это окончания библиотечных функций). Работа эксплоита сводится к построению цепочки вызовов подобных блоков ("гаджетов") для получения нужной функциональности. Для автоматизации выявления гаджетов применяются специальные инструменты. Используя готовые блоки машинных инструкций (гаджеты) можно организовать достаточно сложные операции, в том числе организовать работу условных операторов и циклов.



  1. Главная ссылка к новости (http://undeadly.org/cgi?action...)
  2. OpenNews: Проект OpenBSD представил технику защиты RETGUARD
  3. OpenNews: В OpenBSD добавлена новая защита от атак на основе заимствования кусков кода
  4. OpenNews: Проект OpenBSD перешёл по умолчанию на Clang для платформ amd64 и i386
  5. OpenNews: Разработчики OpenBSD развивают новый метод защиты стека
  6. OpenNews: Разработчики OpenBSD представили криптографическую библиотеку libcsi
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: retguard, openbsd, clang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Crazy Alex (ok), 09:15, 07/06/2018 [ответить] [показать ветку] [···]    [к модератору]
  • +4 +/
    Что-то ни в этой, ни в предыдущей новости не видать ни оценок падения производительности, ни ссылок на таковые. Вроде там не много совсем, но, во-первых, это только одна из "фишек для безопасности" (а сколько в сумме - ещё вопрос), во-вторых - "вроде" - это какая-то не слишком точная оценка.
     
     
  • 2.6, Нанобот (ok), 11:04, 07/06/2018 [^] [ответить]    [к модератору]
  • +/
    ну, это же openbsd... между безопасностью и производительностью они выбирают безопасность (в разумных пределах,я надеюсь)
     
  • 2.7, A.Stahl (ok), 11:19, 07/06/2018 [^] [ответить]    [к модератору]
  • –3 +/
    А кому это важно? Это как потребление топлива болидами Формулы 1: вроде бы и важно, но по факту всех интресует лишь сколько прёт. Так и БСД: просто полигон для экспериментов.
     
     
  • 3.12, Аноним (-), 15:38, 07/06/2018 [^] [ответить]    [к модератору]
  • +7 +/
    >по факту всех интресует лишь сколько прёт

    Ты эту Формулу-1 хоть раз смотрел? Там трассы не настолько прямые, как твои извилины, чтобы всех "интересовало лишь сколько прёт".

    Так и тут. OpenBSD - инструмент, и важно знать его сильные и слабые стороны.

     
     
  • 4.28, тигарэтоя (?), 10:09, 08/06/2018 [^] [ответить]    [к модератору]
  • –1 +/
    про извилину было мощно, нажал плюсик:-)
     
  • 3.21, бедный буратино (ok), 07:00, 08/06/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    вааще-то это самый важный параметр - не больше 100 кг, а дальше крутись, как хош... весь текст скрыт [показать]
     
  • 2.11, Аноним (-), 15:23, 07/06/2018 [^] [ответить]     [к модератору]  
  • +2 +/
    Вы, должно быть, троллите о каком падении производительности может идти речь, к... весь текст скрыт [показать]
     
     
  • 3.15, имя (?), 19:45, 07/06/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Вы, должно быть, троллите о каком возрастании на константу может идти речь в, ... весь текст скрыт [показать]
     
     
  • 4.39, Анонимный Аноним (?), 17:55, 10/06/2018 [^] [ответить]     [к модератору]  
  • +/
    в каждую функцию добавляются следующие инструкции mov r11, cookie xor... весь текст скрыт [показать]
     
  • 2.25, PereresusNeVlezaetBuggy (ok), 09:28, 08/06/2018 [^] [ответить]     [к модератору]  
  • +/
    В ближайшее время, думаю, тов Мортимер выступит где-нибудь с докладом на эту те... весь текст скрыт [показать]
     
  • 2.26, bOOster (ok), 09:33, 08/06/2018 [^] [ответить]     [к модератору]  
  • +/
    Видимо на 1С или Perl или и иже с ними программер знаешь что такое в ассемблере... весь текст скрыт [показать]
     
     
  • 3.35, КО (?), 07:54, 09/06/2018 [^] [ответить]     [к модератору]  
  • +/
    Самое забавное, что описываемые Вами действия нужны только для атаки на алгорит... весь текст скрыт [показать]
     
     
  • 4.38, Анонимный Аноним (?), 17:54, 10/06/2018 [^] [ответить]    [к модератору]  
  • +/
    Он может изменить код только в новых страницах. Загруженные из файла страницы кода не модифицируемы. Эта защита была еще лет 15-20 назад
     
  • 1.3, Аноним (-), 09:41, 07/06/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    В новости не разъяснено, генерируется ли cookie на этапе компиляции или во время... весь текст скрыт [показать]
     
     
  • 2.4, Аноним (-), 09:48, 07/06/2018 [^] [ответить]    [к модератору]  
  • +/
    На этапе компиляции конечно. Генерация на лету была бы излишним усложнением и замедлением. Представляйте сколько нужно выполнить кода для генерации псевдослучайного числа?
     
     
  • 3.5, Аноним (-), 10:12, 07/06/2018 [^] [ответить]    [к модератору]  
  • +/
    Там в каком то примере просто использовалось значение esp/rsp (оно для эксплоита не известно, вычисляется в процессе выполнения)
     
  • 3.9, Аноним (-), 13:36, 07/06/2018 [^] [ответить]    [к модератору]  
  • +/
    Ну в таком случае что мёртвому припарка, только вредная: оверхед то даёт. Атакующий просто вытащит из метода захардкоденный cookie и положит на стэк.
     
     
  • 4.10, Аноним84701 (ok), 14:40, 07/06/2018 [^] [ответить]     [к модератору]  
  • +/
    Однако, чтобы просто вытащить и просто положить на стек для успешного RЕТа, ... весь текст скрыт [показать]
     
     
  • 5.16, Sw00p aka Jerom (?), 01:47, 08/06/2018 [^] [ответить]     [к модератору]  
  • +/
    Во-первых, должно быть наличие баги да, да - вот вам и успешный РЕТ , во-вторых... весь текст скрыт [показать]
     
     
  • 6.20, Аноним84701 (ok), 03:12, 08/06/2018 [^] [ответить]     [к модератору]  
  • +/
    Это те же кексы, вид сбоку индивидуальные для каждой функции Т е и защита... весь текст скрыт [показать]
     
     
  • 7.32, Sw00p aka Jerom (?), 16:04, 08/06/2018 [^] [ответить]    [к модератору]  
  • +/
    Так суть механизма RETGUARD, не от закрытия каких-то багов, а от предотвращения дальнейшей эксплуатации бага (того же переполнения стека). А так если даже предотвращается эксплуатация, но никак не защитит от DOS и приведёт в любом случае к падению приложения. Если имеется возможность как-то получить результат ксора, то легко можно вычислить ту самую куку, которая непонятно когда вычисляется (формируется) на этапе компиляции или в рантайме, одна ли она для всех ретурнов или разная, и внизу в коментах задали наводящий вопрос - а как валидируется потом реальный адресс возврата (хотя его валидация не важна, приложение будет падать при "хер пойми ретурн адресе", а что когда он неожиданно укажет на валидное место?). Доказано - РОП идеальный механизм, которому нужно противодействовать только, как я думаю, попыткой переосмысления всей Фоннеймановской архитектуры, как минимум вынести хранения адресов возврата из стека куда нить в другое место :)
     
  • 5.17, Аноним (-), 01:49, 08/06/2018 [^] [ответить]     [к модератору]  
  • +/
    Если значение захардкодено, то вытащить из скачанного пакета не проблема чтобы ... весь текст скрыт [показать]
     
     
  • 6.19, Sw00p aka Jerom (?), 01:58, 08/06/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > чтобы работало rop, нужно положить на стек. а это типа митигация от
    > ропа.

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


     
  • 3.13, КО (?), 17:06, 07/06/2018 [^] [ответить]    [к модератору]  
  • +/
    >На этапе компиляции конечно. Генерация на лету была бы излишним усложнением и замедлением.

    Да ладно - вон адреса при загрузки в память меняют, так что еще одну константу рандомизировать ...

    Другое дело глупо как-то описано. Для атакующего положить в стек рядом с адресом возврата нули - ксорь по ним не ошибешься дело плевое. Кука должна быть в недоступной для атакующего памяти.

     
  • 2.22, PereresusNeVlezaetBuggy (ok), 09:19, 08/06/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > В новости не разъяснено, генерируется ли cookie на этапе компиляции или во
    > время исполнения. И если во время исполнения, то используется ли безопасный
    > ГПСЧ.

    Во время исполнения. При загрузке программы для каждой функции генерируется персональная кука. С ГПСЧ у OpenBSD всё давно хорошо: https://www.openbsd.org/papers/hackfest2014-arc4random/index.html

    > И если используется, то насколько падает производительность.

    Сборка базовой системы на предпоследней версии патча замедлялась примерно на 11% (результаты авторские, не мои), из них:

    2% рантайм (то, что всем интересно)
    4% запуск (из-за нагрузки на ГПСЧ)
    5% компиляция + всё остальное

    Тод Мортимер (основной автор) обещал попробовать ещё что-то подкрутить, подробностей пока нет.

     
     
  • 3.29, Crazy Alex (ok), 11:37, 08/06/2018 [^] [ответить]    [к модератору]  
  • +/
    Ну вот. Существенно хуже, чем я ожидал, кстати.
     
     
  • 4.30, PereresusNeVlezaetBuggy (ok), 11:40, 08/06/2018 [^] [ответить]    [к модератору]  
  • +/
    > Ну вот. Существенно хуже, чем я ожидал, кстати.

    SSP обычная на момент внедрения отъедала около 5% в рантайме (правда, SSP, в отличие от retguard, используется не для всех функций), так что могло быть и хуже. :)

     
  • 1.8, ляликс (?), 12:33, 07/06/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    в апстрим добавят этот патч? надеюсь...
     
  • 1.14, Аноним (-), 17:32, 07/06/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Я первый раз слышу про RETGUARD Читая вот это возникло несколько вопросов воп... весь текст скрыт [показать]
     
     
  • 2.18, Sw00p aka Jerom (?), 01:52, 08/06/2018 [^] [ответить]    [к модератору]  
  • +/
    > вопрос №2: как после второго XOR для восстановления происходит валидация неизменности
    > адреса возврата?

    а вот это никого не волнует)) если пихать в роп гаджетах разные адреса возвратов, то при ксоре получется адрес возврата "хер пойми куда" и произойдёт, что? сегфолт? а если по вероятности адрес после ксора укажет куда нужно, что тогда?

    добавлю ещё один вопрос - кука одна на один процесс?


     
     
  • 3.24, PereresusNeVlezaetBuggy (ok), 09:24, 08/06/2018 [^] [ответить]    [к модератору]  
  • +/
    >> вопрос №2: как после второго XOR для восстановления происходит валидация неизменности
    >> адреса возврата?
    > а вот это никого не волнует)) если пихать в роп гаджетах разные
    > адреса возвратов, то при ксоре получется адрес возврата "хер пойми куда"
    > и произойдёт, что? сегфолт? а если по вероятности адрес после ксора
    > укажет куда нужно, что тогда?

    Значит, не повезло. Retguard — не серебряная пуля; как и классическая SSP эта мера эффективна только вместе с другими, суммарно увеличивая сложность эскалации атаки на многие порядки.

    > добавлю ещё один вопрос - кука одна на один процесс?

    Одна на каждую функцию, генерится при запуске программы.

     
  • 2.23, PereresusNeVlezaetBuggy (ok), 09:22, 08/06/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > Я первый раз слышу про RETGUARD. Читая вот это:
    >> Суть метода защиты RETGUARD заключается в искажении адреса возврата обработчиков функций. Перед началом обработчика функции добавляется вызов XOR, комбинирующий адрес возврата с генерируемым для каждой функции случайным значением Cookie, которое затем сохраняется в стек. Перед командой возврата управления из функции (ret) значение Cookie извлекается из стека и при помощи операции XOR повторно применяется к адресу возврата, что восстанавливает его исходное значение и позволяет убедиться в том, что адрес перехода не изменился. Для усложнения атак код проверки дополнительно снабжается добавочным заполнением в виде инструкций int03 перед каждой инструкцией ret
    > возникло несколько вопросов:
    > вопрос №1: насколько сложно изменить значение cookie?

    Она живёт в read-only памяти.

    > вопрос №2: как после второго XOR для восстановления происходит валидация неизменности
    > адреса возврата?

    Естественным путём: если в результате XOR получилась фигня, то мы и улетим в результате ret фиг знает куда. При широком (64-битном) адресном пространстве это практически наверняка будет не туда, куда хотел атакующий.

     
     
  • 3.36, КО (?), 16:39, 09/06/2018 [^] [ответить]    [к модератору]  
  • +/
    >значением Cookie, которое затем сохраняется в стек.
    >>Она живёт в read-only памяти.

    ну, пожалуй, read-only stack _действительно_ защитит от возвратного программирования, но при таком подходе печенки излишни. :)

     
     
  • 4.37, PereresusNeVlezaetBuggy (ok), 15:14, 10/06/2018 [^] [ответить]    [к модератору]  
  • +/
    >>значением Cookie, которое затем сохраняется в стек.
    >>>Она живёт в read-only памяти.
    > ну, пожалуй, read-only stack _действительно_ защитит от возвратного программирования,
    > но при таком подходе печенки излишни. :)

    А кто сказал, что эта кука лежит на стеке? Она лежит в памяти по некоему ASLR-нотому адресу. Чтобы утащить куку, да ещё от нужной функции, нужно сделать то, для чего и нужно утащить куку, причём не обрушив программу — при следующем запуске процесса куки будут уже другие. Это не обычный SSP, где куку можно утащить со стека простым чтением за границами буфера.

     
  • 2.40, Анонимный Аноним (?), 17:57, 10/06/2018 [^] [ответить]    [к модератору]  
  • +/
    Патчу уже около года: https://marc.info/?l=openbsd-tech&m=150317547021396&w=2
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor