AppleのmacOSに入っている開発者向けツールが、すでに失効が問題になっている証明書をまだ信頼している――そんな話を、元記事はかなり強い口調で伝えている。対象は git、curl、python3 で、見落としというより、修正が遅れたうえに一度ユーザーが手で回避した状態まで台無しになった、というのが焦点だ。単なる設定ミスに見えて、実際にはHTTPS通信の中身を差し替えられる危険がある。開発者だけの話にとどまらず、CIや供給網にも響くので、今取り上げる意味がある。
元記事が扱っているのは、eMudhra の認証局コンプロマイズ、つまり証明書を発行する側の一部が侵害された件だ。Appleはこの件について17th October に通知を受けたとされているが、28th October の時点でも、macOS に同梱される開発者向けツールはまだその「compromised certificates」を信頼していたという。対象として挙げられているのは git、curl、python3 だ。しかも問題は、単に修正が遅れているだけではない。26th October に出た macOS 27.2 では、この問題を直していなかったうえ、ユーザーが手作業で入れていた回避策まで元に戻してしまい、再び危険な状態にした、と元記事は指摘している。
元記事はこの状態の危険性をかなり具体的に示している。これらのツールが行う HTTPS 接続は、攻撃者に途中で見られたり差し替えられたりしうる。git なら https:// のリモートから clone や pull をしたときに、攻撃者が選んだコードを受け取らされる可能性があるし、push の通信も途中で改変されうる。さらに GitHub tokens のような認証情報まで盗まれるおそれがある、という説明だ。curl や python3 も同じように影響を受けるので、単にリポジトリ操作だけの問題ではない。
元記事では、影響確認のためのコマンドも示している。たとえば git については git ls-remote https://git-emudhra.we-have-a-problem.com/check.git を実行し、証明書エラーになれば保護されている、逆に commit が表示されれば影響を受けている、と説明している。さらに実際の攻撃を再現するデモとして、git -c http.curloptResolve=github.com:443:15.235.19.186 clone https://fake-user@github.com/galadran/emudhra-git-test というコマンドも載せている。これは一時的に github.com をテストサーバーへ向け、そこに eMudhra の侵害された中間証明書のひとつで発行された github.com 証明書を出させる仕掛けだ。パッチ済みの git なら証明書エラーで拒否し、失敗しなければ README.md の先頭に INTERCEPTED と書かれた内容が見えるという。fake-user@ を付ける理由も説明されていて、外さないと本来なら GitHub の認証情報を送ってしまうからだ。curl についてもチェック用 URL が示されており、証明書エラーなら保護済み、そうでなければ影響ありと判定する。
元記事は最後に、Apple は Safari など自社の networking framework 上のアプリはすでに守っている一方で、macOS の開発者向けツールにはまだ修正を出していないと述べる。暫定対応としては、影響を受けた root certificate を /etc/ssl/cert.pem から手で外す方法があるが、Apple の案内では macOS の更新でその修正が戻されることがあるという。だから更新のたびに確認と再適用が必要になる。そして、CI やビルド基盤で macOS runner を使っている組織は、サプライチェーン上のリスクとして見直したほうがいい、と結んでいる。
この話でまず引っかかるのは、Apple が消費者向けの Safari などでは守れているのに、開発者が毎日触る git と curl と python3 の側が置き去りになっている点だと思う。ブラウザが守られるのは当然としても、実際に仕事のコードを運んでいるのはむしろそちらだ。しかも git は単なる取得ツールではなく、リポジトリの内容そのものを信頼する入口になっている。ここが崩れると、ソースコードの取得、レビュー前の検証、ビルド素材のダウンロードまで一気に疑わしくなる。開発者は「会社支給の mac だから安全だろう」と思いがちだが、元記事はその前提が崩れていると示している。
さらに気になるのは、修正が遅れたことだけではなく、26th October の macOS 27.2 がユーザーの手動対処を巻き戻した、という点だ。これは単なる不具合修正漏れより重い。なぜなら、ユーザーは一度リスクを認識して自分で対策しているわけで、それをOS更新が上書きしてしまうと、安心していた環境が再び危険になるからだ。セキュリティ対応では「直っていない」ことより、「直したつもりだったのに戻される」ほうが現場の混乱を大きくする。再確認を毎回強いる設計は、運用コストを静かに押し上げる。
元記事がわざわざ git clone のデモを置いているのは、HTTPS の証明書問題が目に見えにくいからだと思う。証明書の警告は、普段は「面倒だが無視できない何か」くらいに受け取られやすい。でもここでは、証明書が通ってしまえば、攻撃者が用意したリポジトリの中身を本物として受け取ることになる。しかも git は clone だけでなく pull や push にも絡む。つまり、読むだけの操作でも、送るだけの操作でも危ない。GitHub tokens のような秘密情報が途中で抜かれる可能性まであるなら、これはコード改ざんと情報漏えいが同時に起こりうる話だ。
もう一つ大きいのは、元記事が「ネットワーク上の誰か」による攻撃を強調していることだ。http.curloptResolve を使ったデモはあくまで再現用だが、本当に必要なのはその設定ではない。途中経路にいる攻撃者が、自分で通信を曲げればいい。つまり危険なのは特定のサーバーだけではなく、Wi-Fi、社内ネットワーク、VPN、あるいは何らかの中継装置など、経路そのものだ。開発者にとっては「このURLを使っているか」ではなく「この証明書群を信じているか」が問題になる。そこが厄介だ。
元記事の最後に出てくる CI の話は、かなり重要だと思う。個人の Mac での作業だけなら、最悪でも影響範囲はその人の端末に限られる。しかし macOS runner をビルドやテスト基盤で使っていると、そこから出る通信は組織全体の成果物づくりに直結する。たとえば依存コードの取得、パッケージのダウンロード、テスト用データの取得、社内リポジトリへの push などが同じ前提で動いていると、1台の信頼崩れがそのまま供給網の穴になる。元記事が supply chain risk と書いているのは大げさではない。
私が面白いと思うのは、こういうときに組織の「安全」はOSのアップデート方針にかなり左右されることだ。しかも今回のように、Apple がすでに他の製品では対処しているのに、開発者向けの同梱ツールは別扱いになっていると、運用側はどこまで信用していいのか判断しづらい。結局、セキュリティチームは「更新すれば安全」の単純なモデルを捨てて、証明書ストアや同梱ツールのふるまいまで監視する必要がある。便利な標準環境が、そのまま安全とは限らない。そこを突きつける記事だった。
参考: Apple
