| 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 - инструмент, и важно знать его сильные и слабые стороны.
| | |
| 3.21, бедный буратино (ok), 07:00, 08/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Это как потребление топлива болидами Формулы 1
вааще-то это самый важный параметр - не больше 100 кг, а дальше крутись, как хошь - делай, какой хошь (в рамках регламента) двигатель, лишь бы в 100 кг укладывался
| | |
|
| 2.11, Аноним (-), 15:23, 07/06/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вы, должно быть, троллите: о каком падении производительности может идти речь, когда после входа и перед выходом из функции добавляется по паре машинных инструкций? Это сложность возрастает на константу.
| | |
| |
| 3.15, имя (?), 19:45, 07/06/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вы, должно быть, троллите: о каком падении производительности может идти речь, когда после входа и перед выходом из функции добавляется по паре машинных инструкций? Это сложность возрастает на константу.
Вы, должно быть, троллите: о каком возрастании на константу может идти речь в, например, цикле с read()?
| | |
| |
| 4.39, Анонимный Аноним (?), 17:55, 10/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
в каждую функцию добавляются следующие инструкции:
mov r11, [cookie]
xor r11, [rsp]
...
xor r11, [rsp]
cmp r11, [cookie]
jeq 2
int 3
int 3
ret
В случае с циклическим чтением, это добавит около 5 "лишних", но быстрых машинных инструкций. Грубо говоря 5 тактов, если считать, как считали для 80486. Сейчас это намного быстрее
| | |
|
|
| 2.25, PereresusNeVlezaetBuggy (ok), 09:28, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Что-то ни в этой, ни в предыдущей новости не видать ни оценок
> падения производительности, ни ссылок на таковые. Вроде там не много совсем,
> но, во-первых, это только одна из "фишек для безопасности" (а сколько
> в сумме - ещё вопрос), во-вторых - "вроде" - это какая-то
> не слишком точная оценка.
В ближайшее время, думаю, тов. Мортимер выступит где-нибудь с докладом на эту тему. Предыдущая версия того, что было закоммичено, имела потери в рантайме примерно 2%, плюс ещё примерно 4% на запуск. Компиляция тормозилась примерно на 5%.
| | |
| 2.26, bOOster (ok), 09:33, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Видимо на 1С или Perl или и иже с ними программер?
знаешь что такое в ассемблере ТАКТОВ на инструкцию? Так вот сложи, в худшем случае тактов на пихание SALT в стек, в лучшем передача SALT в функци. через регистры, ну и тактов на инструкцию XOR при выходе.
| | |
| |
| 3.35, КО (?), 07:54, 09/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Так вот сложи, в худшем случае тактов на пихание SALT в стек, в лучшем передача SALT в функци. через регистры
Самое забавное, что описываемые Вами действия нужны только для атаки на алгоритм защиты. Ибо по условиям атаки, атакующий может писать в стек (и регистры), но не может создавать страницы с кодом. Таким образом он может подделать и адрес возврата и число по которому надо ксорить (например 0).
А просто два ксора адреса возврата по константе (которую бы неплохо инициализировать при загрузки библиотеки в память) это сущие копейки. Ибо на современном этапе главные тормоза - это лишние обращения в память (промахи в кеше).
| | |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
 > Атакующий просто вытащит из метода захардкоденный cookie и положит на стэк.
Однако, чтобы "просто" вытащить и "просто" положить на стек для успешного RЕТа, нужно таки выполнить свой код. А для этого (по крайней мере, в сценариях, для которых и задумывался RETGUARD) придется успешно "РЕТнуть".
| | |
| |
| 5.16, Sw00p aka Jerom (?), 01:47, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
Во-первых, должно быть наличие баги (да, да - вот вам и успешный РЕТ), во-вторых, РОП для того и придуман, чтобы обходить ограничения не исполняемых (ридонли) сегментов памяти (стек, в случае его переполнения), строится цепочка стек фреймов (РОП геджетов) и происходит эксплуатация.
| | |
| |
| 6.20, Аноним84701 (ok), 03:12, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Во-первых, должно быть наличие баги (да, да - вот вам и успешный РЕТ),
> во-вторых, РОП для того и придуман, чтобы обходить ограничения не исполняемых (ридонли) сегментов памяти (стек, в случае его переполнения), строится цепочка стек фреймов (РОП геджетов) и происходит эксплуатация.
Это те же кексы, вид сбоку (+ индивидуальные для каждой функции). Т.е. и защита как раз от таких багов, при которых перезаписывается адрес возврата. Для того, чтобы (в первый раз) успешно RETнуть, нужно не просто перезаписать RET адрес своим, но и угадать, с каким значением его нужно поXORить, причем конкретно для этого вот блока кода.
Ну и снижение общего количества возможных гаджетов тоже, как пишут, есть.
Если бага из другой разновидности, типа "call/jmp [foo_replaced_addr]", то и обходить сабж, как бы, не нужно.
Ваш Кэп.
| | |
| |
| 7.32, Sw00p aka Jerom (?), 16:04, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– |
Так суть механизма RETGUARD, не от закрытия каких-то багов, а от предотвращения дальнейшей эксплуатации бага (того же переполнения стека). А так если даже предотвращается эксплуатация, но никак не защитит от DOS и приведёт в любом случае к падению приложения. Если имеется возможность как-то получить результат ксора, то легко можно вычислить ту самую куку, которая непонятно когда вычисляется (формируется) на этапе компиляции или в рантайме, одна ли она для всех ретурнов или разная, и внизу в коментах задали наводящий вопрос - а как валидируется потом реальный адресс возврата (хотя его валидация не важна, приложение будет падать при "хер пойми ретурн адресе", а что когда он неожиданно укажет на валидное место?). Доказано - РОП идеальный механизм, которому нужно противодействовать только, как я думаю, попыткой переосмысления всей Фоннеймановской архитектуры, как минимум вынести хранения адресов возврата из стека куда нить в другое место :)
| | |
|
|
| 5.17, Аноним (-), 01:49, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
Если значение захардкодено, то вытащить из скачанного пакета не проблема.
>положить на стек для успешного RЕТа, нужно таки выполнить свой код.
чтобы работало rop, нужно положить на стек. а это типа митигация от ропа.
| | |
| |
| 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% компиляция + всё остальное
Тод Мортимер (основной автор) обещал попробовать ещё что-то подкрутить, подробностей пока нет.
| | |
| |
| |
| 4.30, PereresusNeVlezaetBuggy (ok), 11:40, 08/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну вот. Существенно хуже, чем я ожидал, кстати.
SSP обычная на момент внедрения отъедала около 5% в рантайме (правда, SSP, в отличие от retguard, используется не для всех функций), так что могло быть и хуже. :)
| | |
|
|
|
| 1.14, Аноним (-), 17:32, 07/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я первый раз слышу про RETGUARD. Читая вот это:
> Суть метода защиты RETGUARD заключается в искажении адреса возврата обработчиков функций. Перед началом обработчика функции добавляется вызов XOR, комбинирующий адрес возврата с генерируемым для каждой функции случайным значением Cookie, которое затем сохраняется в стек. Перед командой возврата управления из функции (ret) значение Cookie извлекается из стека и при помощи операции XOR повторно применяется к адресу возврата, что восстанавливает его исходное значение и позволяет убедиться в том, что адрес перехода не изменился. Для усложнения атак код проверки дополнительно снабжается добавочным заполнением в виде инструкций int03 перед каждой инструкцией ret
возникло несколько вопросов:
вопрос №1: насколько сложно изменить значение cookie?
вопрос №2: как после второго XOR для восстановления происходит валидация неизменности адреса возврата?
| | |
| |
| 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, где куку можно утащить со стека простым чтением за границами буфера.
| | |
|
|
|
|
