本文へ
ハクソク

世界を動かす技術を、日本語で。

一部のx86 CPUにおけるハードウェアバックドア

元記事: 原文(github.com)

概要

project:rosenbridge は、x86 CPUに存在する ハードウェアバックドア を明らかにするリサーチプロジェクト。 このバックドアは ユーザーランドからカーネル領域への不正アクセス を可能にする。 主に VIA C3 CPU が影響を受ける。 リポジトリには 検出・無効化ツールやリサーチ資料 が含まれる。 この脆弱性の発見・検証方法と対応策を解説。

project:rosenbridge とは

  • x86プロセッサ に埋め込まれた ハードウェアバックドア の存在を示すプロジェクト
  • Christopher Domas (@xoreaxeaxeax) による研究活動
  • デスクトップ、ノートPC、組み込み向けx86 CPU の一部に影響
  • ユーザーランド（ring 3）コード が カーネル（ring 0）データ へ自由にアクセス可能となる問題
  • 通常は カーネル権限での有効化が必要 だが、初期状態で有効なシステムも存在

rosenbridge バックドアの仕組み

  • x86コアとは別に、非x86コア （hidden core）がCPU内部に埋め込まれている
  • モデル固有レジスタ（MSR） の制御ビットで有効化、 特定命令 で起動
  • 専用フォーマットのx86命令 でコマンドをhidden coreへ送信
  • 全てのメモリ保護・権限チェックをバイパス して命令実行
  • Management EngineやPlatform Security Processor とは異なり、 より深くCPU内部に存在
  • CPUの全メモリ、レジスタ、実行パイプライン にアクセス可能

影響を受けるシステム

  • VIA C3 CPU のみが対象と考えられている
  • 産業用オートメーション、POS、ATM、医療機器、一般向けPC などに利用
  • C3以降の世代 にはこの機能は存在しない

脆弱性の意義と今後

  • 脆弱性の 影響範囲は限定的
  • 後続CPU世代では廃止
  • 複雑化するプロセッサ設計 におけるバックドアのリスク例としてのケーススタディ
  • 研究者・エンドユーザーによる発見・対策の参考資料

影響確認と対策方法

  • 影響調査手順

    • git clone https://github.com/xoreaxeaxeax/rosenbridge
    • cd rosenbridge/util
    • make
    • sudo modprobe msr
    • sudo ./bin/check
    • ベアメタル環境必須 （仮想マシン不可）
    • アルファ版ツール のため、非対応CPUではクラッシュやフリーズの可能性

  • バックドアの無効化手順

    • cd fix
    • make
    • sudo make install
    • reboot
    • カーネル権限を持つ攻撃者 による再有効化は防げない
    • システムごとにスクリプトの調整が必要

研究に用いられたツール・技術

  • sandsifter ：未知命令の発見用ファジングツール
  • asm ：Deeply Embedded Instruction Set（DEIS）用アセンブラ
  • esc ：バックドアを利用した権限昇格のPoC
  • fix ：脆弱性の暫定的な修正スクリプト
  • fuzz ：x86/rosenbridgeコア両方のファジングツール群
  • deis ：hidden coreの挙動調査用ファザー
  • exit ：DEIS命令終了後のx86コア復帰シーケンス探索用
  • manager ：分散ファジングタスク管理用Pythonツール
  • wrap ：sandsifterの簡易版、bridge-instruction探索用
  • kern ：カーネルメモリ・レジスタの変化モニタ用
  • lock ：バックドアのロック/アンロックツール
  • proc ：ファジングログ解析用パターン識別ツール
  • test ：hidden coreのアーキテクチャ推定用
  • util ：rosenbridge影響判定用アルファツール

参考文献・免責事項

  • ホワイトペーパー・スライド は今後公開予定
  • 本研究は VIAプロセッサの設計上の特徴 を調査・修正する目的
  • 悪意のある意図は否定、組み込み市場向け機能が誤って有効化された可能性

著者情報

  • Christopher Domas (@xoreaxeaxeax) によるリサーチプロジェクト

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

これ、もうかなり古い話だけど、今でもめっちゃ関連性あるよね。みんなあんまり注目してないけど、TPUユニットのチップが複雑化してるのに加えて、NVIDIAみたいなドキュメントが不十分なハードウェアへのシフトが、この問題に新たな火をつけてる。ドマス（もしかしたら彼のチームや同僚も？）は、ここ数年で高度なマルウェアやインプラント、カントールダストみたいな興味深い素材をたくさん出してるんだ。彼は自分のCPUファズァーやMSRファズィング技術を使って、ハードウェアのバグやバックドアを通じて攻撃を見つけて、逆アセンブルして、実装してる。バックドアが悪意のあるものかデバッグ用かは確認できないけど、要するにそれによって得られる能力が重要なんだ。彼の動画で見せてる技術は、そんなに難しくないから、興味がある人はぜひ挑戦してみて、再現して、この分野での認識や発見を広める手助けをしてほしいな。もう一つの良いアプローチは、Defcon 21 - デキャッピングチップスだよ。人々はNPMやPipなどのサプライチェーンの問題について話してるけど、これらはもっと深刻で検出が難しい。ほとんど誰も見てないし、大抵のベンダーは完全に無視してる。だって、これに対抗する製品を売れないからね。（もし検出したらハードウェアを廃棄する必要があるから、売上には不利だし…）

└

Cantor Dustが何か知らなかったから、いくつかの検索結果をクリックして、抽象的な説明を越えて基本的なアイデアを形成するまで時間がかかったよ。要するに、バイナリデータフォーマットのための「ブロッキー」みたいなものだと思ってる。WAV音声ファイルやビットマップ、ASCIIテキスト、マシンコードなど、それぞれ独自の視覚的なサインを生成するんだ（でも、同じカテゴリ内の異なる例は似たようなサインを生成することが多い）。だから、異なるタイプのデータの「ブロッキー」を学ぶと、こういう見方をすると本当に目立つんだよね（「あ、あの1と0の並びの中に画像が埋まってる！」みたいな）。このページの説明は悪くないし、下の方にあるビットマップの例が特にわかりやすいよ（ページの上の方でビットマップの参照画像を見た後なら）： https://inside.battelle.org/blog-details/battelle-publishes-... 自分の知識はまだ20分くらいのものだけど、これが誰かの学び始めるきっかけになればいいな！

└

ATMや医療機器向けに販売されているチップにおいて、デフォルトで有効になっているドキュメントが不十分または未記載の（デバッグ用の）バックドアは、少なくとも無謀な危険行為として分類されるね。

それって、VIAが悪意を持ってこのバックドアを意図的に追加したってことなのかな？それとも、他に合理的な説明があるの？

└

同じことを考えてたんだけど、これってもう古いCPUだよね、2001年に登場したやつだし。開発中や発売時には、ほとんどの人がまだWindows 95/98/MEを使ってて、もっと深刻なセキュリティ問題があった（ほぼ全てのユーザーが管理者だったし）。もしかしたら、便利な（デバッグ用？）機能だったのかもね？

└

無害な説明もあるよ。VIA C3は、x86命令を内部のシンプルな命令形式に変換する、かなりシンプルなCPU設計なんだ。複雑なx86の動作は、通常は長いマイクロコードや複雑な状態機械で実装されるけど、VIAは自社のCPUをIntelやAMDよりもシンプルにしたかったんだ。だから、この内部命令セットをBIOSに公開して、ハードウェアの初期化を処理させるようにして、その後安全にこの機能をロックする方法を文書化したんだ。一部のBIOS作成者は、仕様を全部読まなかったり理解できなかったりしたみたい。うーん、確か、少なくともこの代替命令セットを実行時に公開して、CPUコアのパフォーマンスを向上させることを考慮していたヒントもあったと思う。例えば、使えるレジスタを増やしたり、3オペランド命令を増やしたり、DSPワークロードのための飽和演算やパックド演算とかね。

このバックドアは、数十年前のVIA C3埋め込み型x86プロセッサにしか現れないんだ。

└

それは、GitHubのREADMEの最初の行に書くべきだったよね。テキストの奥深くに埋もれさせるんじゃなくて。

└

それに、今回の脆弱性は約10年前に公開されたものだってことも覚えておくべきだね。でも、その時点でもVIAのCPUは15年以上前のものだったし。

└

そもそも「バックドア」じゃなくて、データシートにちゃんと載ってるんだよね… http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... （82ページ）…それに、C3のマイクロアーキテクチャはすでに公に知られてるから、この発言は完全にナンセンスに聞こえる。ローゼンブリッジのバックドアは、CPUのメインx86コアの横に埋め込まれた小さな非x86コアだって。最初に出たとき、x86に詳しい何人かと一緒にこれを笑ったのを覚えてるよ。自称「セキュリティ研究者」が、どうにかしてマニュアルを読まなかったんだよね。今ではウィキペディアにも記事があって、代替命令セットのドキュメントへのリンクもあるよ: https://en.wikipedia.org/wiki/Alternate_Instruction_Set

└

確かに、特定のバックドアがこの記事のポイントじゃないね。これは警告の話だよ。要するに、MCUレベル以上のほとんどすべてのシステム、さらにはその中のいくつかは、ドキュメントがないか、ハードウェア設計者が使うことを想定していない低レベルのシステムを持ってることが多い。そういうシステムは、システムリソースへの非常に低いレベルのアクセスを持ってることがある。例えば、動きのデータ、動画、音声、ライダー画像を記録するデバイスを作ってるんだけど、6ドルのIMUや12ドルのライダーセンサーの中には、メーカーが提供するバイナリブロブを読み込む強力なプロセッサーが入ってる。ライダーは、SPIバスに保存されているシステムデータにアクセスできる可能性があるし、それにはシステムの大容量ストレージやセカンダリRAMも含まれてる。レーザーを使って数百メートル以内の誰かにそのデータを持ち出すこともできるし、光学センサーを通じてリモートでコマンドを受け取ることもできる。そうならないようにしているのは、そのブロブにそういうことをするコードが含まれていないと信じているからだけど、簡単にそういうコードが入ったブロブに置き換えられる。基本的なWi-Fi機能を持つデバイスが何百万台も作られていて、これは専用のWi-Fiモジュールの形で提供されることが多い。ほとんどが、プロプライエタリなバイナリブロブを動かす強力なプロセッサーで構成されていて、システムの内部バスに接続されていて、デバイスの機能の一部またはすべてにアクセスできるか、少なくともデバイスが正常に動作しない原因になることがある。これらのWi-Fi PHYモジュールは1ドル未満で、広く普及していて、接続機能が宣伝されていないデバイスにも組み込まれていることが多い。もしその不透明なブロブの攻撃面について知識を持っている脅威アクターがいれば、その製品で作られた接続デバイスの50%以上を故障させることができるだろうし、場合によっては深刻で危険な方法でデータを持ち出すこともできる。これがこの記事の本質だよ。

これを見ると、クローズドソースのCPUを作ってる大企業は信頼できないってことがわかるよね。政府が求めるものを何でも追加するだろうし。これを軽減するために何ができるかな？一つの選択肢は、大きなFPGAを買ってオープンソースのCPUでフラッシュすること。もう一つは、CPUをエミュレートして、暗号化されたデータやコマンドで動かすこと。そうすれば、ホストCPUのバックドアがメモリを上書きしようとしても、エミュレートされたOSだけがクラッシュすることになる。もう一つの選択肢は、QEMUのような仮想マシンでコードを実行することで、コードを翻訳して未知の命令を発行させないようにすることだね。

Hacker Newsで議論の続きを見る

同じ出典の記事