CVE-2023-42829; 'アプリがSSHパスフレーズにアクセスできる可能性がある'

この文書では、macOSのsshバイナリで特定されたロジック脆弱性（私にとって初めてのソフトウェア脆弱性です！）の分析と、Appleがどのようにその脆弱性を修正したかを示すパッチ分析の両方を提示します。2022年末にApple Security Bountyプログラムを通じてこの問題をAppleに報告し、その後macOS Ventura 13.5で修正され、CVE-2023-42829（🎉）が発行されました。この問題により、macOSのユーザーローカル「ログイン」キーチェーン（com.apple.ssh.passphrasesアクセスグループ内）に保存されたSSHパスフレーズが、ローカルの攻撃者に平文で公開されることになります。

免責事項：
このレポートは教育目的のみで提供されており、責任ある開示プロセスが遵守されています。分析は現状のまま提供され、この情報のさらなる公開や使用は責任ある開示ガイドラインに従うべきです。

パッチ適用後のハイレベルフロー

パッチ適用前のハイレベルフロー

テスト済みハードウェアとソフトウェア

ハードウェア	OSソフトウェア
MacBook Pro M1 2021	`/usr/bin/ssh` @ macOS Ventura build 13.0.1 (22A400)

例/PoC

以下の概念実証は、sshバイナリの-Iフラグに動的ライブラリを渡すことで、この脆弱性がかなり簡単に悪用可能であることを示しています：

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

これがどのように発見されたのか、そしてなぜ発生したのかについて説明しましょう！

分析

かつて、私はsshバイナリを何か無害な用途で使っていたとき、-iフラグ（SSHアイデンティティファイルを渡すために使用）を-Iとタイプミスしてしまい、次のstdoutが表示されました：

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), ...
...

その後、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>

...興味が湧きました。このバイナリには保護されたキーチェーンアクセスグループ（com.apple.ssh.passphrases）から読み取るエンタイトルメントがあり、com.apple.private.security.clear-library-validationエンタイトルメントを保持しており、さらにsshが私の秘密鍵をdlopen()しようとしている？

実際のところ、sshはpkcs11と呼ばれるものを介したリモートシステムへの認証をサポートしています。pkcs11はハードウェアセキュリティモジュール（HSM）での暗号化操作の標準です（https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library.html）。

この記事の目的では、クライアントがssh -Iにpkcs11（動的ライブラリ）ライブラリを供給するという事実以外、pkcs11の詳細を心配する必要はありません。

`com.apple.private.security.clear-library-validation` エンタイトルメント

概念的には同等ですが、com.apple.private.security.clear-library-validationは、以前の同等のエンタイトルメント（com.apple.security.cs.disable-library-validation）とは異なります。com.apple.private.security.clear-library-validationでは、csops()システムコールにCS_OPS_CLEAR_LVを渡してライブラリ検証の有効/無効を制御し、実行時のプロセス整合性をより細かく制御する必要があります（com.apple.private.security.clear-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のコンテキスト内でコードを実行し、keychain-access-groupsエンタイトルメントを利用できます。

パッチ分析

おそらくパッチは、csops()を呼び出す前にバイナリに対して特定の信頼された署名IDをチェックする処理を含んでいたのでしょうか？

いいえ！

パッチリリース（22G74）後、pkcs11_add_provider()（dlopen()の呼び出しが行われるメソッド）の安全でない実装を比較しましたが、パッチリリースと同一に見えました。しかし、/usr/bin/sshにエンタイトルメントが欠けている？

<?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がSSHからpkcs11サポートを削除したはずはない？私はPoCを使って脆弱性の再悪用を試みたところ、ライブラリはロードされたものの、もはやキーチェーンアクセスグループから読み取ることができず、以前に見たことのないバイナリ/usr/libexec/ssh-apple-pkcs11のコンテキストで実行されているように見えました。このバイナリは以下のエンタイトルメントを持っています：

<?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>

CS_OPS_CLEAR_LVのcsops()システムコールのコメント（https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/kern_proc.c）は、CS_OPS_CLEAR_LVと組み合わせて使用するのではなく、ライブラリ検証なしでバイナリに再execすることを代替手段として言及しています。では、追加のヘルパーバイナリが存在するのに、なぜ/usr/bin/sshのpkcs11_add_provider()に論理的に欠陥のあるルーチンがまだ存在するのでしょうか？また、なぜパッチで実装が変更されていないように見えるのでしょうか？

実は、パッチはヘルパーバイナリを追加するのではなく、macOSに2つのsshバイナリを配布するものでした：/usr/bin/sshと/usr/libexec/ssh-apple-pkcs11 - それらのエンタイトルメントを除けば両者は同一です（これをDiaphoraを使って検証しました）：

パッチ適用済みのsshバイナリに対していくつか動的分析を行ったところ、sshの（かなり大きな）start()ルーチンに追加のチェックが追加されていました。これはpkcs11機能を使用する際に、バイナリが/usr/bin/sshのコンテキストで実行されているのか、それとも/usr/libexec/ssh-apple-pkcs11のコンテキストで実行されているのかを推測するために使われます：

ssh-apple-pkcs11への再execを引き起こすチェックを示す制御フローグラフ

緑色のブロックでは、SecTaskCopyValueForEntitlement()への呼び出し（渡される値は "com.apple.private.security.clear-library-validation"）を確認できます。これは（オレンジ色のブロックで）評価され、現在のタスク/プロセスに"com.apple.private.security.clear-library-validation"エンタイトルメントが存在しない場合、（赤色のブロックで）再execルーチンへの条件付き呼び出しを引き起こします。

これにより、ユーザーが供給したpkcs11ライブラリをロードする際には、エンタイトルメントが少ないssh-apple-pkcs11バイナリが使用され（実質的にsshのキーチェーン関連機能が無効化されます）、信頼できないライブラリをロードしない状況ではsshが使用されます（sshのキーチェーン関連機能が有効になります）。

また、パッチ適用済みをデバッグすることで、これが事実であることを検証できます

パッチ適用済みのsshバイナリ（macOS 22G74で配布）をデバッグし、execv()にブレークポイントを設定すると、-Iフラグを指定したときにexecv()への呼び出しを実際に確認できます。これはpkcs11機能を使用せずにsshを起動した場合には発生しません：

結論 / 対処

2022年末にApple Security Bountyプログラムを通じてこの問題をAppleに報告し、その後macOS Ventura 13.5で修正され、CVE-2023-42829（🎉）が発行されました。

この記事は独立した出版物であり、Apple Inc.による承認、支援、またはその他の承認を受けていません。macOS、iOS、およびiWorkはApple Inc.の商標です。

CVE-2023-42829

人気