Pre-auth RCE в Apple Screen Sharing: root за 60 секунд из-за забытого кода ошибки

Исследование, опубликованное на warez.sl0p.foo, описывает критическую уязвимость в демоне общего доступа к экрану screensharingd на macOS вплоть до версии 26.5 (Tahoe). Проблема затрагивает все системы с включённой функцией «Общий экран» и не требует ни пароля, ни имени пользователя, ни какого-либо участия жертвы.

Один забытый регистр

В основе бага — классическая ошибка обработки ошибки. Демон читает из сети четырёхбайтовую длину кадра SRP, а затем проверяет её. Если длина оказывается слишком большой (≥ 32768), срабатывает ветка «кадр слишком велик» — но вместо кода ошибки функция возвращает залежавшийся статус предыдущей операции чтения, то есть ноль. А ноль вызывающий код трактует как «аутентификация успешно завершена».

В результате весь механизм SRP — генерация ключей, вычисление и проверка сессии — просто не выполняется. Сервер выставляет флаг authenticated = 1, отправляет клиенту подтверждение и переходит в основной цикл обработки сообщений RFB. Никакого обмена ключами, никакого согласования шифра: соединение работает открытым текстом, хотя протокол в норме поднимает слой ChaCha20-Poly1305.

От байта к root-шеллу

Дальше в дело вступает проприетарный протокол копирования файлов Apple (тип сообщения 0x22), работающий от имени root и дающий произвольные чтение и запись файлов. Атака укладывается в одно TCP-соединение: злоумышленник присылает версию RFB, тип безопасности 36 и один большой блок данных. В нём упакованы две транзакции записи — Perl-скрипт обратного шелла в /var/tmp/.r и crontab в /var/at/tabs/root (обязательно с правами 0600, иначе cron его проигнорирует).

В течение минуты cron подхватывает задание и запускает штатный, подписанный Apple /usr/bin/perl, который открывает атакующему root-шелл. После срабатывания оба файла самоуничтожаются. Эксплойт зависит от раскладки кучи и срабатывает примерно в одном случае из 5–15, поэтому по умолчанию делается до 20 попыток.

Отдельно авторы отмечают вторую, независимую слабость: сервер отвергает публичное значение A == 0, но не A ≡ 0 (mod N), что противоречит RFC 5054 и позволяет обнулить общий секрет, отправив A = N. В самом эксплойте она не используется.

Патч и любопытная деталь

Уязвимость исправлена в macOS 26.6, вышедшей 27 июля 2026 года: ветка «слишком большой кадр» теперь возвращает корректный ненулевой код ошибки. Пользователям без обновления рекомендуется просто отключить общий доступ к экрану.

Любопытнее всего дисклеймер: по признанию авторов, весь разбор, PoC и шаги воспроизведения были полностью произведены ИИ-агентами на основе статического анализа и автоматического тестирования, без участия человека. Отсюда и оговорка, что материал может содержать ошибки и требует независимой проверки.

Источник: Lobsters