В современном мире кибербезопасности платформы Apple на macOS считаются одними из самых защищенных операционных систем благодаря множеству встроенных механизмов контроля и ограничений. Одним из важных элементов защиты является система ограничений запуска приложений, призванная гарантировать, что бинарные файлы запускаются только при соблюдении строгих условий. Однако в 2025 году появилась информация о новой уязвимости под идентификатором CVE-2025-43253, позволяющей обойти эти ограничения, что вызвало интерес как у специалистов по безопасности, так и у технической аудитории в целом. Разберёмся, что такое ограничения запуска на macOS, как работает уязвимость, и что значит для безопасности пользователей. Ограничения запуска (launch constraints) в macOS представляют собой набор условий, предписанных системой для запуска конкретных бинарных файлов.
Они обозначаются Apple как lightweight code requirements (сокращённо LWCR). По сути, это словари настроек, где указаны правила, необходимые для разрешения запуска процесса: например, запуск разрешён только с системного тома или разрешён только при запуске инициализирующим процессом init. Эти ограничения можно назвать своеобразным уровнем доверия, встроенным в ядро системы, обеспечивающим защиту от несанкционированного запуска потенциально опасных модификаций системных приложений и демонов. Применение этих ограничений серьёзно ограничивает возможности злоумышленников, пытающихся создать поддельные версии системных приложений, перенести их в обход системы в неизведанные директории или использовать «плагинные» атаки с модификацией кода. Таким образом, launch constraints служат значимым барьером, раздражающим злоумышленников и минимизирующим многие классы эксплойтов.
Выявление уязвимости CVE-2025-43253 было связано с попытками исследователя по имени Ноа Грегори разработать инструменты для реверс-инжиниринга и более глубокого взаимодействия с ядром macOS. Во время работы с функцией posix_spawn() — системным вызовом, ответственным за запуск новых процессов из пользовательского режима — исследователь наткнулся на возможность вставлять произвольные данные в атрибуты запуска процессов с помощью функции posix_spawnattr_setmacpolicyinfo_np. Это открывало дверь к особенностям реализации механизма TrustedBSD MAC Framework, встроенного в ядро XNU (ядро macOS). TrustedBSD MAC Framework позволяет реализовывать полиси безопасности, связанные с контролем различных аспектов работы системы. Эти политики могут регистрировать обратные вызовы для анализа поведения процессов, в том числе при их запуске.
Конкретная функция mpo_proc_check_launch_constraints_t вызывается для проверки ограничений запуска. Любопытным оказалось, что данные, подаваемые в эту функцию, берутся именно из атрибутов, передаваемых в posix_spawn() — что создаёт уязвимое связующее звено. Эксплуатация данной уязвимости не сопровождается типичными ошибками памяти или переполнениями, которые обычно ассоциируются с критическими уязвимостями ядра, но носит иной и простоватый по сути характер. Исследователь обнаружил, что можно передавать собственный словарь ограничений запуска как blob (байтовый массив) в полиси AMFI (Apple Mobile File Integrity), которая отвечает за проверку целостности и безопасности приложений архитехтуры macOS. Благодаря этому механизму можно заменить встроенные строгие ограничения системы на менее строгие или даже практически пустые условия, что даёт возможность запускать процессы, которые в обычных условиях были бы заблокированы.
Такой обход ограничений означает, что злоумышленник теоретически может запускать модифицированные системные компоненты с меньшими проверками безопасности. Однако и здесь есть тонкости. Функция обработки ограничения принимает параметр «категория ограничения», который определяет, насколько строго следует применять переданные условия. Удивительным образом оказалось, что категория с номером 127, хоть и разрешена для передачи через spawn атрибуты, не подвергается проверке и не вызывает ошибок при нарушениях ограничений. Эта особенность и была использована для обхода системы безопасности.
Для помощи в подготовке таких словарей существует специальная и не очень хорошо задокументированная библиотека libTLE.dylib в macOS, которая позволяет сериализовать структуры ограничений в формат, подходящий для передачи AMFI. Это облегчает создание необходимых «поддельных» ограничений для обхода механизма проверки. Несмотря на значимость уязвимости, исследователь отмечает, что в реальной эксплуатации найденный обход ограничений пока не дал возможности получить полный контроль над системой или реализовать успешную атака. Дополнительные системы защиты, такие как AppleSystemPolicy, продолжают блокировать запуск модифицированных приложений, сохраняя общую безопасность системы на достойном уровне.
Впрочем, появление уязвимости такого рода заставляет специалистов по безопасности быть особенно внимательными к развитию архитектуры защиты macOS. Ведь механизм вызова проверки ограничений через пользовательские атрибуты spawn создает потенциал для новых видов атак или обходов. Именно поэтому Apple оперативно выпустила патч, в котором теперь оба набора ограничений — как встроенные системные, так и переданные через spawn атрибуты — проверяются одновременно. Это значительно повышает надёжность проверки. Важным техническим аспектом является опция безопасности, позволяющая включать или отключать проверку сторонних ограничений запуска.
Она присутствует в sysctl под именем security.mac.amfi.launch_constraints_3rd_party_allowed. По умолчанию эта опция была включена, что и позволило злоумышленнику воспользоваться уязвимостью, однако в патче логика обработки была переписана и доработана.
До этого, как выяснилось, у некоторых исследователей эта опция была выключена, что и не давало возможности обнаружить уязвимость в полном объёме. Появление CVE-2025-43253 и открытое исследование по ней подчёркивают необходимость постоянного анализа и тестирования инфраструктуры безопасности современных систем. Даже самые продвинутые архитектуры могут иметь узкие места, и своевременное выявление таких недостатков — ключ к защите конечных пользователей. Также стоит отметить, что CVE-2025-43253 — не единственная уязвимость, замеченная в последние месяцы. Тот же исследователь упоминал о CVE-2025-43266, которая остаётся пока без подробного публичного раскрытия по разным причинам, включая сложность анализа и оперативные соображения.
