Apple curl セキュリティ事案 12604
(daniel.haxx.se)- macOS に Apple がバンドルした curl は、
--cacertオプションをオープンソースビルドとは異なる形で処理し、ユーザーが指定した CA のみを信頼するという TLS 検証の期待を崩している --cacertはサーバー証明書を 指定した CA 証明書集合 のみで検証させるオプションであり、検証に失敗した場合は curl がエラーを返さなければならない- Apple 提供の curl は、指定 CA による検証に失敗しても システム CA ストア を追加で確認しているようで、この動作は要求されておらず文書化もされていない
- Apple Product Security は、Apple の OpenSSL である LibreSSL が組み込みのシステム信頼ストアをデフォルトの信頼ソースとして意図的に使用しているため、修正対象ではないと回答した
- curl プロジェクト配布版の脆弱性ではないため CVE は発行されなかったが、macOS バンドル版 curl の CA 検証結果はドキュメントと異なる可能性がある
Issue 12604 の始まり
- 2023 年 12 月 28 日、curl の Issue トラッカーに bugreport 12604 が登録された
- Issue のタイトルは「flag --cacert behavior isn’t consistent between macOS and Linux」で、Yuedong Wu が報告した
- 同じ macOS マシンで同じ curl バージョンを実行しても、Apple バンドル版 curl とオープンソースからビルドした curl バイナリでは挙動が異なっていた
--cacert が期待させる保証
- curl コマンドラインオプション
--cacertは、以後の転送で curl が 正確に指定された CA 証明書集合 のみを信頼するようにする方法である - TLS サーバーがその証明書集合で検証可能な証明書を提示できなければ、curl は失敗してエラーを返すべきである
- このオプションは 2000 年 12 月に curl に追加され、ユーザーが認識し信頼しているサーバーと通信していることを確認するための機能である
- つまり、TLS が果たすべき基本的な役割に直接関わっている
macOS バンドル版 curl の例外的な動作
- Apple が提供する macOS 向け curl は、
--cacert使用時に指定された CA 証明書集合での検証に失敗すると、システム CA ストア を追加で確認しているように見える - この補助的な確認はユーザーが要求した動作ではなく、文書にもないため予測しにくい
- ユーザーが縮小した専用の CA 証明書ファイルで検証しようとしても、システム CA ストアにサーバーを検証できる証明書があれば失敗しない
- その結果、本来通過してはいけない 証明書検証 が通ってしまう可能性があり、セキュリティ問題とみなされる
Apple Product Security の回答
- 2023 年 12 月 29 日 08:30 UTC に Apple Product Security へセキュリティ問題の報告メールが送られた
- Apple Product Security は 2024 年 3 月 8 日に回答した
- Apple の回答は 2 点に要約できる
- Apple の OpenSSL である LibreSSL は、組み込みのシステム信頼ストアをデフォルトの信頼ソースとして意図的に使用している
- サーバー証明書は組み込みのシステム信頼ストアで正常に検証できるため、Apple プラットフォーム側で対処すべき問題とは見なしていない
- Apple はこのケースをクローズした
curl プロジェクト側の判断とユーザーへの影響
- macOS におけるこの 文書化されていない機能 により、curl の CA 証明書検証はドキュメントと一貫しなくなっている
- ユーザーは
--cacertで指定した CA 証明書集合のみが使われると期待するが、Apple 提供の curl はその期待どおりには動作しない - この問題は curl プロジェクトが配布する curl バージョンのセキュリティ脆弱性ではない
- curl プロジェクトはこの問題に対して CVE を発行していない
- 問題は curl コード自体ではなく、Apple がプラットフォームで提供し curl ビルドに使用している LibreSSL のバージョンに起因する
- macOS で Apple 提供の curl を使う場合、
--cacertベースの検証結果はオープンソースビルドの curl と異なる可能性がある
1件のコメント
Hacker Newsのコメント
その挙動は完全に愚かです。自分で CA を指定するなら、理由は二つのうちどちらかです。自分の CA が OS のバンドルに入っていないか、特定の CA だけで検証したいからです。
つまり Apple のこの「機能」は、無駄な計算を増やすか、期待していた検証モデルを壊すかのどちらかです。どちらも望ましい結果ではありません。
それでも期待した結果ではないので、悪い挙動だという点には同意します。Apple は通常、後方互換性を壊す変更を好むこと、そしてこの機能が curl に追加されたことを考えると、Apple が明かしていない事情がほかにもありそうです。開発者向け診断ツールや AppStore の検証に使われているのかもしれません。
残念ながら、Apple デバイスの「所有者」が何をしようとしても常に Apple のポリシーが優先される、こうした挙動は驚くことではなく、Apple では常に予想しておくべきことです。
少なくともデジタル生活のその部分では合わず、価格を考えると横にもう一台置くデバイスとして買うのも難しいです。Apple 製品を試してみようかとずっと考えてきましたが、最近では AR ヘッドセットもそうでしたし、今のところ開発者やいじり屋に対してあまりに敵対的に見えました。
Apple ほど大きな会社が「ユーザーのデバイスを所有する」という大きなビジョンのためにこの判断をしたと見るのは、Apple に組織的・調整能力をとてつもなく大きく見積もることになります。Apple の 10 分の 1 の規模の組織でも聞いたことがないレベルです。でも Apple だから、そうなんでしょう!?
おそらく Apple がこれを設定しているのでは？[0] 強調は私によるものです。
CURLSSLOPT_NATIVE_CAlibcurl に、証明書検証で OS のデフォルト CA ストアを使うよう指示します。このオプションを設定し、CA 証明書ファイルやディレクトリも併せて設定すると、検証中にそれらの証明書もデフォルト CA ストアと一緒に検索されます。
--cacertとこのオプションが組み合わさると、libcurl は両方を尊重しようとしているように見えます。両者は相互排他的であるべきではないのでしょうか？curlバイナリはlibcurlライブラリをどう呼び出すべきかを知っています。これはバックドアです。
意図的または悪意があると言っているわけではありません。しかし実質的にはバックドアです。ユーザーの認証体系に鍵を追加し始めたなら、バックドアを追加したことになります。
デフォルトの挙動が疑わしいのは確かですが、この評価にはまったく同意しません。実際これは curl のドキュメント化の問題です。
curl はマルチプロトコルライブラリなので、すべてのプロトコルを自前で実装しているわけではなく、多くの場合、低レベルのビット解釈を外部に任せる推移的依存関係の「バックエンド」に依存しています。一部のプロトコルでは、妥当な理由から複数の代替ライブラリのサポートを含んでいます。
このアプローチの欠点は、独立したバックエンド間で共通の挙動を保証するのが難しい、または不可能なことです。同じ機能をすべて提供していないかもしれず、API が不完全な場合もあり、今回のようにデフォルト挙動の一部をパッチする手段を提供していない場合もあります。LibreSSL は OpenSSL をビット単位で再実装したものではなく、その API を完全にまねる義務もありません。
このような場合、アップストリームが修正を渋るなら、curl には二つの選択肢が残ります。そのライブラリのサポートを切るか、その特異な挙動を文書化するかです。前者はユーザーコードを壊す可能性があるので、少なくとも後者は行うべきです。
とはいえ、この方式が LibreSSL のセキュリティ観点で欠陥だという大筋には同意しますし、おそらく CVE を開く理由があるかもしれません。ただし対象は LibreSSL であるべきです。
SQLite の F_BARRIERFSYNC 事件を思い出します。
単に気にしていないのです。
https://bonsaidb.io/blog/acid-on-apple/
彼らのメンテナンス姿勢は、Debian の人が OpenSSL を壊した件より二段階ほど下です。
Daniel があなたたちの curl は壊れていると言うなら、直せばいいだけです、Apple。そんなに単純な話です。
ここでは 2 分確認した限り、おそらく正しいように見えますが、「Daniel だから正しい」というのは最悪の論理です。
C の歴史、特に Eric S. Raymond の「貢献」をめぐる古い会話を思い出します: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...
警告ありがとう。ちなみに私は MacPorts で macOS にバンドルされているツールのかなり多くを置き換えて使っています。curl もその一つです。
バンドルされたツールはたいてい古いか、別の形で壊れています。Apple のバンドルソフトウェアへの信頼はずっと前に失いました。
Apple が何か重要なものをこの挙動に依存させているのではないかと気になります。
誰かが内部のプライベート CA だけを使うようにスクリプトを作るのは完全に合理的です。このコマンドを実行すれば、内部企業 CA なので内部企業リソースとだけ通信していると分かります。
ところが Apple はここに、ドメイン検証と同じくらい大きなバックドアを追加しました。
さらに、ダミー名を使い、会社 CA が署名したという事実だけで会社のサーバーに接続していることを確認するのも十分に妥当です。ところが Apple はこの非常に合理的な前提を壊し、セキュリティ脆弱性を作ったのです。よくありません。
Apple がユーザーのセキュリティを気にしているという話も、この程度だったのですね