CVE-2023-42829; «Приложение может получить доступ к SSH-паролям»

В этом документе представлен как анализ логической уязвимости, обнаруженной в бинарном файле ssh в macOS (моя первая уязвимость в программном обеспечении!), так и анализ исправления, демонстрирующий, как Apple устранила уязвимость. Я сообщил об этой проблеме в Apple через программу Apple Security Bounty в конце 2022 года, позже проблема была исправлена в macOS Ventura 13.5, и ей был присвоен CVE-2023-42829 (🎉). Проблема приводит к тому, что парольные фразы SSH, сохранённые в локальной связке ключей пользователя macOS (Login Keychain) в группе доступа com.apple.ssh.passphrases, становятся доступны локальному злоумышленнику в открытом виде.

Отказ от ответственности:
Этот отчёт предоставляется исключительно в образовательных целях, при этом были соблюдены процессы ответственного раскрытия информации. Анализ предоставляется как есть, а любая дальнейшая публикация или использование этой информации должны соответствовать правилам ответственного раскрытия.

Исправленный высокоуровневый поток

Неисправленный высокоуровневый поток

Содержание

Проверенное оборудование и программное обеспечение
Пример/PoC
Анализ уязвимости
Entitlement com.apple.private.security.clear-library-validation
Анализ исправления
Ссылки

Проверенное оборудование и программное обеспечение

Оборудование	ПО ОС
MacBook Pro M1 2021	`/usr/bin/ssh` @ macOS Ventura build 13.0.1 (22A400)

Пример/PoC

Следующее доказательство концепции иллюстрирует довольно простую эксплуатацию уязвимости: передача динамической библиотеки через флаг -I бинарного файла ssh:

jamesd@local build % ssh -I /Users/jamesd/rome.dylib [email protected]
SSH Private Key Passphrase -> 'SuperSecret!!@@$'

Давайте обсудим, как это было обнаружено и почему это произошло!

Анализ

Однажды я использовал бинарный файл ssh для чего-то безобидного и случайно ввел флаг -I вместо -i (используется для передачи файла идентификации SSH), после чего увидел следующий вывод:

jamesd@local build % ssh -I /Users/jamesd/.ssh/id_rsa something@somewhere
dlopen /Users/jamesd/.ssh/id_rsa failed: dlopen(/Users/jamesd/.ssh/id_rsa, 0x0002): tried: '/Users/jamesd/.ssh/id_rsa' (not a mach-o file), ...
...

После проверки entitlements бинарного файла ssh...

jamesd@local build % ldid -e /usr/bin/ssh # dump the entitlements of the /usr/bin/ssh binary

<key>com.apple.private.security.clear-library-validation</key>
    <true/>
    <key>keychain-access-groups</key>
    <array>
        <string>com.apple.ssh.passphrases</string>
</array>

...моё внимание привлекло то, что бинарный файл имеет entitlements для чтения из защищённой группы доступа связки ключей (com.apple.ssh.passphrases), обладает entitlement com.apple.private.security.clear-library-validation, и ssh пытается выполнить dlopen() для моего закрытого ключа?

Как оказалось, ssh поддерживает аутентификацию на удалённой системе через нечто, называемое pkcs11, — стандарт для криптографических операций на аппаратных модулях безопасности (HSM) (https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library.html).

Для целей этой статьи нам не нужно вдаваться в подробности pkcs11, кроме того факта, что клиент предоставляет библиотеку pkcs11 (динамическую библиотеку) в ssh -I.

Entitlement `com.apple.private.security.clear-library-validation`

Хотя концептуально эквивалентен, com.apple.private.security.clear-library-validation отличается от предыдущего аналогичного entitlement (com.apple.security.cs.disable-library-validation) тем, что для com.apple.private.security.clear-library-validation требуется выполнить системный вызов csops() с передачей CS_OPS_CLEAR_LV для управления включением/отключением проверки библиотек, чтобы сохранить больший контроль над целостностью процесса во время выполнения (по сравнению с com.apple.security.cs.disable-library-validation, который, предположительно, позволяет загружать любую библиотеку без контроля во время выполнения). (https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/kern_proc.c) (https://theevilbit.github.io/posts/com.apple.private.security.clear-library-validation/)

Диаграмма, показывающая вызов csops для отключения проверки библиотеки перед вызовом dlopen

Поскольку csops(CS_OPS_CLEAR_LV) вызывается перед dlopen() нашей библиотеки, наша библиотека просто загружается, и конструктор выполняется, что позволяет нам предоставить вредоносную динамическую библиотеку, маскирующуюся под библиотеку pkcs11, и выполнить код в контексте /usr/bin/ssh, используя entitlement keychain-access-groups.

Анализ исправления

Возможно, исправление включало проверки бинарного файла перед вызовом csops() для проверки конкретных доверенных идентификаторов подписи?

Нет!

После выпуска исправления (22G74) я сравнил небезопасную реализацию pkcs11_add_provider() (метод, в котором происходит вызов dlopen()) и она оказалась идентичной исправленной версии — но в /usr/bin/ssh отсутствует entitlement?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>keychain-access-groups</key>
    <array>
        <string>com.apple.ssh.passphrases</string>
    </array>
</dict>
</plist>

Но неужели Apple удалила поддержку pkcs11 из SSH? Я попытался повторно эксплуатировать уязвимость с помощью своего PoC и обнаружил, что, хотя моя библиотека загрузилась, она больше не могла читать из группы доступа связки ключей и, казалось, выполнялась в контексте /usr/libexec/ssh-apple-pkcs11 (бинарный файл, которого я раньше не видел), который обладает следующими entitlements:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.private.security.clear-library-validation</key>
    <true/>
</dict>
</plist>

Комментарий в системном вызове csops() для CS_OPS_CLEAR_LV (https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/kern_proc.c) упоминает перезапуск (re-exec) в бинарный файл без проверки библиотек как альтернативу CS_OPS_CLEAR_LV, а не использование вместе. Так почему же логически ошибочная процедура всё ещё присутствует в pkcs11_add_provider() в /usr/bin/ssh, если теперь есть дополнительный вспомогательный бинарный файл? И почему реализация в исправлении выглядит неизменной?

Как выяснилось, исправление заключалось не в добавлении вспомогательного бинарного файла, а в распространении двух бинарных файлов ssh в macOS: /usr/bin/ssh и /usr/libexec/ssh-apple-pkcs11 — оба идентичны, за исключением их entitlements (я использовал Diaphora для проверки):

diaphora diff бинарных файлов ssh-apple-pkcs и ssh

После проведения динамического анализа исправленного бинарного файла ssh в (довольно большой) процедуре start() была добавлена дополнительная проверка, которая используется, при использовании функций pkcs11, для определения, выполняется ли бинарный файл в контексте /usr/bin/ssh или /usr/libexec/ssh-apple-pkcs11:

граф потока управления, показывающий проверку, вызывающую повторное выполнение в ssh-apple-pkcs11

В зелёном блоке мы видим вызов SecTaskCopyValueForEntitlement() (передаётся значение "com.apple.private.security.clear-library-validation"), который затем (в оранжевом блоке) оценивается и вызывает условный вызов процедуры перезапуска, если entitlement "com.apple.private.security.clear-library-validation" отсутствует для текущей задачи/процесса (красный блок).

В результате при загрузке предоставленной пользователем библиотеки pkcs11 используется менее привилегированный бинарный файл ssh-apple-pkcs11 (фактически отключая функции ssh, связанные со связкой ключей), а ssh используется там, где не следует загружать ненадёжные библиотеки (включая функции ssh, связанные со связкой ключей).

Мы также можем подтвердить это, отладив исправленный бинарный файл ssh (распространяемый в macOS 22G74) и установив точки останова на execv() — мы действительно можем заметить вызов execv() при использовании флага -I, который не происходит при запуске ssh без использования функций pkcs11:

вызов execv в исправленном бинарном файле ssh

Заключение / Устранение

Я сообщил о проблеме в Apple через программу Apple Security Bounty в конце 2022 года, позже она была исправлена в macOS Ventura 13.5, и ей был присвоен CVE-2023-42829 (🎉).

Эта статья является независимой публикацией и не была авторизована, спонсирована или иным образом одобрена Apple Inc. macOS, iOS и iWork являются товарными знаками Apple Inc.

CVE-2023-42829

Популярное