Comments 4
Хорошо бы к статьям о программировании делать минимально рабочий git репозитарий с демонстрацией решаемой проблемы
Я боюсь этот трюк быстро прикроют, это по сути считается уязвимостью
Мне кажется, это достаточно хороший вопрос, можно ли это назвать уязвимостью. Если можно – то в чем заключается ущерб от неё?
Если говорить о том, что приложение благодаря таким "трюкам" может запросто выполнять какой-нибудь небезопасный код, полученный извне, то это будет возможно всегда. Чтобы такое ограничить, это нужно либо mmap над исполняемыми страницами ограничивать (что сломает очень много чего, в том числе JIT), либо политику агрессивного код-сигнинга вводить (как сделали Apple). А вот меры уровня "давайте запретим файлы выполнять" в целом не решают данный вопрос.
А вот какой вопрос они решают – так это, вероятнее всего, чтобы в уже существующих уязвимых приложениях снизить вероятность успешной атаки (первое что приходит в голову: приложение запускает процесс с потенциально "небезопасным" pathname и с ограничениями будет сложнее заменить его на что-то полезное для атакующего)
Ну вот новые приложения которые будут этот трюк использовать могут оказаться тоже "небезопасными" и кто-то опять таки будет их эксплуатировать таким же образом, как и те о которых вы говорите про существующие. Значит всё равно придётся закрывать. По сути закрывая этот механизм будут решать ровно ту же проблему, которую решали изначально запрещая запуск исполняемых файлов.
А вообще сама суть в хитром обходе ограничений ОС, по сути это privilege escalation в каком-то смысле, очень напоминает ситуации как некоторые уязвимые suid приложения использовали для запуска под рутом своего кода, только здесь в качестве уязвимого приложения выступает сам linker. Единственный плюс что тут нет смены пользователей, но повышение SELinux прав тут однозначно есть.
Запуск бинарных файлов из data/data на Android 10+ (Обход SELinux)