> И по этому их программы люди не используют.Нет, это не так. Было бы хорошо, если бы это было так, но это не так и игнорировать это нельзя.
> На целевой системе нет firefox и chrome. Кроме них есть куча бровзеров которые по умолчанию ответственно относятся к безопасности и приватности пользователей.
Ясно-понятно.
> Firefox JIT нужен только для поддержки расширений. Можно расширения устанавливать пакетным менеджером в систему и отключить их поддержку firefox. Это правильный и безопасный путь. Почему его не используют разработчики дистрибутивов?
Потому что никто не хочет лепить свои костыли вместо стандартных возможностей ff во имя не пойми чего?
> В моем дистрибутиве пакетный менеджер умеет, для кривого софта, выставлять нужные PAX флаги!
Круто! Я тоже могу наколхозить кучу всего интересного (или не очень) и забавного. Кому какое дело до этого? Это очевидно нишевое решение. И не буду даже спрашивать откуда вы берёте pax-патчи, с тех пор как их закрыли вместе с grsecurity/.
> Тео, вместо этого, добавил ненужную дыру.
Я попробую ещё, но, пожалуй, последний раз в этой теме.
Так вот.
Какая проблема решается W^X pt 2, он же PAX MPROTECT?
Если даже у нас уже реализован и используется W^X pt 1, мы всё равно можем внедрить код, сделать ret2libc->ret2mprotect = сделать память исполянемой, выполнить код. Защита преодолена, W^X нарушен.
PAX MPROTECT прибивает процесс, который вызывает mprotect, добавляющий PROT_EXEC, таким образом, решающий проблему (и ломающий некоторые "честные" приложения).
В случае OpenBSD, реализован только W^X pt 1, prot_exec может быть только отозван через pledge, что требует модификации кода программы.
Помимо этого, в любом случае возникнут сложности на этапе ret2libc, так как используется ASLR и при каждой новой загрузке ОС используется заново слинкованная libc с расположенными в случайном порядке объектами. Т.е. произвести атаку, конечно, всё-таки возможно, но это едва ли получится с первой попытки, да и в целом, будет несколько затруднено.
OpenBSD хочет соблюдать стандарты, а не извращённо толковать иx (из "If an implementation cannot support the combination of access types specified by prot, the call to mprotect() shall fail." люди из pax делают вывод, что имеют право ломать mprotect, в дествительности написать имплементацию которая поддерживает кобминацию w и x вполне можно, так что...).
Поэтому аналог PAX MPROTECT не может быть включен по умолчанию. Однако, так как хоть какие-то меры противодествия имеются, а ROP в более широком смысле, нежели описанный выше пример, всё равно может позволить обойти W^X pt 2, принятые по-умолчанию меры считаются примемлемыми.
А при использовании pledge можно и поставить точку в вопросе с prot_exec, и подобная логика может быть добавлена в программы достаточно легко.
Проще говоря, назвать это дырой сложно, эксплуатировать что-то в реальной жизни будет сложнее, чем в теории.
> PaX отключить принципиально, теоретически и практически невозможно
С трудом представляю, как ты пользуешься такой системой, а главное - зачем. См. выше, почему я считаю, что ты страдаешь за почти что иллюзию защиты.
