Copilotをroot化した方法

• 2025年4月、Copilot Enterprise にリアルタイムPythonサンドボックス（Jupyter Notebookベース）が追加され、バックエンドでのコード実行が可能になった
• Jupyter Notebookの %command 構文により、基盤システム上で任意コード実行が容易で、Linuxコマンドも ubuntuユーザー（miniconda環境） として実行できた
• /app/miniconda/bin パスがubuntuユーザーに書き込み可能で、rootの $PATH でも優先されているため、pgrep などの主要コマンドを上書きできるセキュリティ脆弱性が存在した
• これを悪用してroot権限を取得したが、コンテナ内部は厳格に隔離されており、コンテナ脱出は不可能で、追加の情報漏えいもなかった
• 当該脆弱性は4月の報告後、7月に 中程度のリスク としてパッチが適用され、報奨金はなくリサーチャー一覧への掲載のみとなった

---

Microsoft Copilot Enterprise Jupyter Sandbox 脆弱性分析

Copilot Enterprise Jupyter環境の概要

• 2025年4月から Copilot Enterprise に Jupyter NotebookベースのPythonサンドボックス が導入された
• ユーザーはJupyterの %command 構文を通じてLinuxのシステムコマンドを実行できる
• 環境はminicondaベースの ubuntu ユーザー権限で実行され、sudo バイナリは存在しない
• 環境変数、ネットワーク、ファイルシステム、プロセス情報などを幅広く探索できる

コンテナ内部の動作と構造

• CopilotはChatGPT sandboxと似ているが、新しいカーネルとPython 3.12を使用している
• 主なプロセス: Jupyter Notebook、Goで書かれた goclientapp（port 6000で実行）、httpproxy など
• ネットワークでは loopback と制限された link-local インターフェースのみが有効
• ファイルシステムはOverlayFSで /legion パスを基盤とし、/app にカスタムスクリプトが存在する

ダウンロードとファイル操作

• テキスト/コマンド出力ファイルは通常どおりダウンロード可能だが、バイナリファイルは破損の恐れがあるため base64 エンコードが必要
• ファイルは /mnt/data に配置され、blob URL形式で外部ダウンロードリンクが生成される

goclientapp / httpproxy の構造

• goclientapp: 外部から /execute エンドポイントで受け取ったコード（JSON形式）をJupyter環境で実行し、結果を返す
• httpproxy: Jupyterから外部へ出るHTTPトラフィックをプロキシする（ENABLE_EGRESS=false により無効化状態）

entrypoint.sh スクリプトの脆弱性

• コンテナのエントリポイントスクリプト entrypoint.sh では、複数のサービス（goclientapp, httpproxyapp）が ubuntu ユーザー権限で実行される
• keepAliveJupyterSvc.sh だけが root として継続実行される
• 28行目の pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888" コマンドは、$PATH 内ディレクトリの優先順位に従って動作する
• /app/miniconda/bin が root と ubuntu ユーザーの両方の PATH で /usr/bin より前にある → pgrep のようなコマンドを任意に置き換え可能

root権限取得の過程と限界

• 攻撃者は /app/miniconda/bin に悪意ある pgrep スクリプトを作成し、entrypoint.sh が root 権限でこのファイルを定期的に実行するよう仕向けた
• このスクリプトは /mnt/data/in ファイルを読み込んでシェルコマンドとして実行し、結果を /mnt/data/out に保存する
• この方法でコンテナ内の root 権限取得には成功したが、/root 内のファイルなどの機微情報やログにはアクセスできず、コンテナ脱出も不可能だった
• コンテナは各種 breakout シナリオがすべて修正済みだった

Microsoftの対応と結果

• 2025年4月18日: Eye Security が MSRC に脆弱性レポートを提出
• 2025年7月25日: Microsoft が 中程度の深刻度（moderate severity） と分類し、パッチ適用後に問題をクローズ、リサーチャー一覧に掲載（バグバウンティ支払いなし）

参考と付録

• Eye Security は欧州拠点のサイバーセキュリティ企業で、24/7脅威監視、インシデント対応、サイバー保険などを提供している

• この脆弱性を含む Microsoft 社内サービス（Entra OAuth など）への侵入事例は BlackHat USA 2025 で発表予定

• タイムライン

  • 2025年4月18日 – MSRC に報告
  • 2025年7月25日 – パッチ適用およびケース終了、ブログ公開

[GN⁺]

Hacker Newsのコメント

• この脆弱性の核心は、本来はコンテナ内部で一般ユーザー権限しか与えない設計だったものを、トリックを使って root 権限でコード実行できた点にあると理解している。しかし実際には、コンテナ自体が非常に厳格に隔離されていて、ネットワークアクセスもできず、脱出も不可能だったため、root 権限でできることは自分のコンテナを壊すことくらいしかなかった
  • Microsoft が本当に徹底してセキュリティ設定していたことは認める。大半の企業はここまで完璧には隔離していない
  • このコンテナが正確にどう実装されていたのかは分からない。Microsoft は Python サンドボックスの隔離に標準的な方式（Azure container-apps session）を使っているので、この機能もそれを使っていたか、あるいは似た方式であってほしい
  • Copilot がある時はコード実行を拒否し、別の時は許可するのが少し奇妙に感じる。どこまでを目標にしているのか気になる
  • 最近は脆弱性が一つのスタックのように積み重なるので、「コンテナは安全だ」というのは、攻撃者がまだ脆弱性を見つけていないという意味にすぎない。コンテナ脱出や VM 脱出もすでに知られた攻撃手法であり、設定ミスや virtio ドライバのバグのような小さなミス一つでも突破されうる。この事例は実際に重要な結果だ
• 「How We Rooted Copilot」のようなタイトルを見ると、実際に Copilot の中核 VM を突破したのかと思ったが、実際には極めて制限された Python サンドボックスコンテナで root 権限を得ただけだった。より正確なタイトルは「How We Rooted the Copilot Python Sandbox」だろう
  • 「完全に隔離されたサンドボックスで一般ユーザーから root への権限昇格に成功した」程度に要約できる。実際にはあまり意味のない結果だが、むしろサンドボックスが防御にどれだけ有効かを示す事例でもある
• ここでハッキングの全過程を見ることができる
• 私はこの件を Python サンドボックスを脱出してコンテナまで突破したものだと理解していた。Microsoft が脆弱性の深刻度を moderate と評価したのも、こうした文脈によるものだと思う
• 何か見落としているのかもしれないが、ローカルネットワーク経由だけでも外部へネットワーク接続を試みることはできないのだろうか？ Microsoft が顧客に対して、こうしたコンテナ内で root 権限まで許しつつも、データ流出や追加攻撃の危険は本当になかったのか気になる
  • 以前 openai が Python インタープリタ機能を公開した時も状況は似ていた。外部ネットワークアクセスは遮断されており、面白かったのは内部設定ファイル数個と、開発者たちのコーディング方法に関する一部の情報だけだった。今回の事例も事実上ほぼ同じだ
• Copilot が示した応答が本物なのか、それともでたらめ（hallucination）なのか、どうやって分かるのだろう？ 自分はそこで働いているが、ああいうプロセスは見たことがない。参考までに、公開リポジトリで keepAliveJupyterSvc.sh というスクリプトを見つけた
  • そのリポジトリとそのコントリビューターたちは、実際に MS/Azure 所属としてコンテナ内 Python コード実行サービスを開発中のようだ。なぜ個人アカウントに上がっているのかは分からない。Office プロジェクトのフォークだとは言っているが、元は見つけられない
  • でたらめではないかもしれない。Copilot のコードが GitHub の学習データセットから生成された可能性もある
  • これは本当にでたらめ（hallucination）のように感じる。チャットボットはたいていトークン生成器にすぎない。実際にプログラムを実行して応答しているのではなく、GPU でトークンを生成して英語に変換して送っているだけだ
• 昔の LLM は非公開の企業文書を学習データに使って会社の機密をよく露出させていた、という話があった。今はたいていデータが精査されているように思う
  • LLM が偶然一度だけ現れたデータを記憶するわけでもないし、実際に非公開データが大量に学習された事例も見たことがない。だから非現実的だと思う。LLM のでたらめが、見た目には本物の機密流出のように見えるだけかもしれない
  • 私の経験では、会社の機密というものは他社にとっては大して意味がない
  • こういう事例に具体例があるのか気になる。私は見たことがない
  • 以前は（非技術系の）企業でもガイドラインなしに導入して、本来の目的と違うコンテンツを生成することもあった。たとえば、ボバティー会社が無料・登録不要の LLM を出していて、私は ChatGPT 無料版が出る前にそこで bash スクリプトをいくつか作って使っていたことがある
  • 出典が気になる
• 実質的には脆弱性ではないようにも見える。このシステムの目的自体が、コードをコンテナ内で実行させる構造だからだ
  • もちろん、コンテナが隔離されているという前提がある場合に限る
• Copilot に sudo バイナリを base64 で渡してから使う方法で、もっと簡単に回避できた気もする
  • それならファイル所有者も root に変える必要がある
• Microsoft に脆弱性を報告したが、moderate に分類されてバグバウンティはもらえず、acknowledgement だけだった。これほど大きな企業が報奨金すら出さないのは正直よく分からない。こういう状況で悪いことが起きないのか疑問だ
  • 本質的には何も得ていない。root 権限を得ても、アクセスできなかったコンテナの一部分を探索できるようになっただけで、/root にもファイルはなく、使えるログも残っていなかった。既知の脱出手法もすべてすでにパッチ済みだった。もし Microsoft がこうした回避方法一つひとつすべてに報奨を出していたらきりがないので、危険性がない限り別途報酬しないのもある程度は理解できる
  • なぜ人々がトリリオンダラー級の巨大企業に無償でバグレポートを出すのか、本当に理解できない
  • Microsoft が金を出さないなら、せめてスワッグくらいは配ったほうがいい気がする。かっこいいグッズをハッカーに渡せば自然に宣伝にもなるし、むしろ入社したくなるかもしれない。ハッカーコミュニティ文化を活用する必要がある
  • 「root」を取っても、実際に得られるものは何もない。いろいろ試してみても成果はなかった