https://www.opennet.me/openforum/vsluhforumID3/114520.html В состав компилятора Clang, используемого для сборки базовой системы OpenBSD, интегрирован (http://undeadly.org/cgi?action=article;sid=20180606064444) механизм защиты RETGUARD, нацеленный на усложнение выполнения эксплоитов, построенных с использованием заимствования кусков кода (https://ru.wikipedia.org/wiki/%D0%92%D0%BE%D0%B7%D0%B2%D1%80%D0%B0%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#.D0.97.D0.B0.D0.B8.D0.BC.D1.81.D1.82.D0.B2.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.D0.BA.D1.83.D1.81.D0.BA.D0.BE.D0.B2_.D0.BA.D0.BE.D0.B4.D0.B0) и приёмов возвратно-ориентированного программирования (ROP, Return-Oriented Programming). <br>Механизм включен только при сборке для архитектуры AMD64.<br><br><br><br>Суть метода защиты RETGUARD заключается в искажении адреса возврата обработчиков функций. Перед началом обработчика функции добавляется вызов XOR, комбинирующий адрес возвра https://www.opennet.me/openforum/vsluhforumID3/114520.html#40 Sun, 10 Jun 2018 14:57:55 GMT Патчу уже около года: https://marc.info/?l=openbsd-tech&m=150317547021396&w=2<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#39 Sun, 10 Jun 2018 14:55:37 GMT в каждую функцию добавляются следующие инструкции:<br><br> mov r11, [cookie]<br> xor r11, [rsp]<br> ...<br> xor r11, [rsp]<br> cmp r11, [cookie]<br> jeq 2<br> int 3<br> int 3<br> ret<br><br>В случае с циклическим чтением, это добавит около 5 "лишних", но быстрых машинных инструкций. Грубо говоря 5 тактов, если считать, как считали для 80486. Сейчас это намного быстрее<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#38 Sun, 10 Jun 2018 14:54:04 GMT Он может изменить код только в новых страницах. Загруженные из файла страницы кода не модифицируемы. Эта защита была еще лет 15-20 назад<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#37 Sun, 10 Jun 2018 12:14:11 GMT &gt;&gt;значением Cookie, которое затем сохраняется в стек.<br>&gt;&gt;&gt;Она живёт в read-only памяти.<br>&gt; ну, пожалуй, read-only stack _действительно_ защитит от возвратного программирования, <br>&gt; но при таком подходе печенки излишни. :) <br><br>А кто сказал, что эта кука лежит на стеке? Она лежит в памяти по некоему ASLR-нотому адресу. Чтобы утащить куку, да ещё от нужной функции, нужно сделать то, для чего и нужно утащить куку, причём не обрушив программу &#8212; при следующем запуске процесса куки будут уже другие. Это не обычный SSP, где куку можно утащить со стека простым чтением за границами буфера.<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#36 Sat, 09 Jun 2018 13:39:00 GMT &gt;значением Cookie, которое затем сохраняется в стек.<br>&gt;&gt;Она живёт в read-only памяти.<br><br>ну, пожалуй, read-only stack _действительно_ защитит от возвратного программирования, но при таком подходе печенки излишни. :)<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#35 Sat, 09 Jun 2018 04:54:13 GMT &gt; Так вот сложи, в худшем случае тактов на пихание SALT в стек, в лучшем передача SALT в функци. через регистры<br><br> Самое забавное, что описываемые Вами действия нужны только для атаки на алгоритм защиты. Ибо по условиям атаки, атакующий может писать в стек (и регистры), но не может создавать страницы с кодом. Таким образом он может подделать и адрес возврата и число по которому надо ксорить (например 0).<br> А просто два ксора адреса возврата по константе (которую бы неплохо инициализировать при загрузки библиотеки в память) это сущие копейки. Ибо на современном этапе главные тормоза - это лишние обращения в память (промахи в кеше).<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#32 Fri, 08 Jun 2018 13:04:35 GMT Так суть механизма RETGUARD, не от закрытия каких-то багов, а от предотвращения дальнейшей эксплуатации бага (того же переполнения стека). А так если даже предотвращается эксплуатация, но никак не защитит от DOS и приведёт в любом случае к падению приложения. Если имеется возможность как-то получить результат ксора, то легко можно вычислить ту самую куку, которая непонятно когда вычисляется (формируется) на этапе компиляции или в рантайме, одна ли она для всех ретурнов или разная, и внизу в коментах задали наводящий вопрос - а как валидируется потом реальный адресс возврата (хотя его валидация не важна, приложение будет падать при "хер пойми ретурн адресе", а что когда он неожиданно укажет на валидное место?). Доказано - РОП идеальный механизм, которому нужно противодействовать только, как я думаю, попыткой переосмысления всей Фоннеймановской архитектуры, как минимум вынести хранения адресов возврата из стека куда нить в другое место :)<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#30 Fri, 08 Jun 2018 08:40:10 GMT &gt; Ну вот. Существенно хуже, чем я ожидал, кстати.<br><br>SSP обычная на момент внедрения отъедала около 5% в рантайме (правда, SSP, в отличие от retguard, используется не для всех функций), так что могло быть и хуже. :)<br> https://www.opennet.me/openforum/vsluhforumID3/114520.html#29 Fri, 08 Jun 2018 08:37:43 GMT Ну вот. Существенно хуже, чем я ожидал, кстати.<br>