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

AMDが修正しないRCE

概要

  • 新しいゲーミングPCでAMD AutoUpdateソフトの問題を発見
  • アップデートURLが安全でも、実際の実行ファイルダウンロードはHTTP通信
  • 攻撃者によるMITM攻撃やRCE脆弱性のリスク
  • 実行ファイルの署名検証が未実装
  • AMDは報告を「対象外」として対応せず

AMD AutoUpdateソフトの脆弱性調査

  • AMD AutoUpdateソフト による定期的なコンソールウィンドウの表示
  • 実行ファイルの特定と リバースエンジニアリング の実施
  • app.config ファイルにアップデートURLを保存
    • 本番環境でも「Development」用URLを利用
    • HTTPS通信を使用し一見安全に見える設計
  • ブラウザでアップデートURLを確認
    • ダウンロードURLは HTTP通信 を利用
    • ネットワーク上の攻撃者やISPを掌握する国家による MITM攻撃 の危険性
  • ダウンロードされた実行ファイルの 署名検証未実装
    • ソフトウェアは検証せずに即座にファイルを実行
    • 任意コード実行(RCE) につながる重大な脆弱性

AMDへの脆弱性報告と対応

  • 脆弱性を AMD へ報告
    • 重大な問題と判断し、早期報告を実施
  • AMDの対応
    • 報告内容を「 wont fix/out of scope」としてクローズ
    • 脆弱性として認定せず、修正の意思なし

タイムライン

  • 27/01/2026 脆弱性発見
  • 05/02/2026 AMDへ報告
  • 05/02/2026 報告クローズ
  • 06/02/2026 ブログ公開

関連情報

  • 他のリサーチ事例:「 1.4 Billion exposed user records via insecure Firebase instances in top Android apps

Hackerたちの意見

これ、めっちゃヤバいよね?これが動いてるやつは、超基本的なHTTPリダイレクトからのインストーラー攻撃に脆弱になるってことだよね?しかも、これってめっちゃ多くのマシンにインストールされてる可能性が高いんだよね?こんなに簡単に悪用できるものがこんなに広まってるの見たことないわ。空港でWi-Fiホットスポット開いて、ATIグラフィックス使ってる人をほぼ即座に攻撃できるんじゃない?

空港に座ってWi-Fiホットスポットを開いて、すぐにATIグラフィックスを使ってる人をハックできるんじゃないの? 自動更新を有効にしてない人もいるし(自動更新はWin98時代からの愚かさの極みだよ)。空港にいる時は、すべてのプログラムを更新するわけじゃないしね。

知らない人のホットスポットに接続する人なんているの?でも、地元のISPの悪い奴にとっては簡単そうだね。

WONTFIXなんて、なんでわざわざやるの?nginxのLetsEncryptを前に立てるのと同じくらいの時間で済むのに。

DNSルックアップを一回妥協するだけで十分ってことだね。例えば、1. 家庭用ルーターが侵害されて、DHCP/DNS設定が変更される。2. ww2.ati.comに対して間違った(悪意のある)IPを報告する。3. HTTPトラフィックをスヌーピングして、悪意のあるバイナリを注入するチャンスを探す。4. HTTPSトラフィックはそのまま通過する。 __________ もしまだデフォルトの管理パスワードを使ってる家庭用ルーターがあるなら、これをちょっとした警告と考えてね。新しいパスワードが付箋に書いてあるだけでも、確実に改善だよ。でもリスクは続くよ:* 被害者のルーター設定が安全なら、LAN内の攻撃者がDHCPスプーフィングを使ってターゲットを別のDNSサーバーに誘導するかも。* 攻撃者は自分がコントロールする別のネットワークを設定して、ユーザーを本物のカフェや「無料Wi-Fi」みたいな曖昧なものに接続させることができる。

SSIDのスプーフィングやジャミングを使えば、誰かを悪意のあるWiFiネットワークに参加させるのは普通に簡単だよ。

DNSの応答をスプーフィングするだけで、先に届けば十分じゃない?

彼らはこれを脆弱性とは考えてないんだよ。単に彼らのバグバウンティプログラムの範囲外だと言ってるだけ。

彼らのスコープ文書には深刻なセキュリティバグがあるみたいだね。

明らかに、彼らのバグ修正プログラムの範囲外みたいだけど、特権コード実行をリモートで簡単に悪用できるのにね。中間者攻撃はAMDにとっては「範囲外」かもしれないけど、実際の攻撃者にとっては「範囲内」だよ。無視するのは無能すぎる。無視する方針は、無能であることを認めるようなものだね。

実行ファイルの更新URLが普通のHTTPを使ってるのは好きじゃないけど、AMDはプログラム内で中間者攻撃や物理的アクセスを必要とする攻撃は範囲外だと明言してるんだよね。このルールが範囲外であるべきかどうかは別の問題だけど、もっと気になるのは、彼らのXMLファイルに開発用と本番用のURLが両方存在してることと、本番で開発用のURLを使ってること。著者が言ったように、URLがTLS/SSLを使ってるから「安全」だとしても、実行ファイルのURLが両方のXMLファイルで同じかどうか気になるな。もし違ったら、その二つの実行ファイルのバイナリ比較をするかも。面白い差異があって、バグバウンティにつながるかもしれない。例えば、開発版にしかないデバッグツールがあって、本番では使うのが危険で、悪用につながる可能性があるとか、なんでか知らないけど本番で開発用のURLを使ってるみたいだし…。

は別の問題だ。いや、違う。これは別の問題じゃない。100%この問題だよ。仮に俺が国家の攻撃者でリソースがあるとする。俺は自分のエクスプロイトを書いて、ドライバーホストが解決するIPをBGPハイジャックする。これで、同時に数百万のホストを侵害したことになる。これがAMDの問題じゃなかったなんて、誰が気にすると思う?

支払いについては、もしかしたらだけど、これはAMDの定義に関係なく100%高優先度のセキュリティ問題だよ。それなのに、支払いをしないから修正もしないみたいだね。

Linuxがすべてのドライバーをバンドルしてることの良い点は、ほとんどの低品質(というか、スパイウェアそのもの)なドライバー管理ソフトを使う必要がなくなることだね。特に問題なのは、他のプロプライエタリなもののように簡単にサンドボックス化できないこと。理由はわからないけど、無料で働いてるディストリビューションのメンテナが、数十億ドルのハードウェアベンダーよりもセキュリティに関してはずっと有能に見える。

何であれ、無償で働いているディストリビューションのメンテナーたちは、億ドル規模のハードウェアベンダーよりもセキュリティに関してはずっと有能に見える。 億ドルのハードウェアベンダーが本当にセキュリティに無能だとは思わないけど、ディストリビューションのメンテナーたちはセキュリティをかなり気にしているのに対して、ハードウェアベンダーはそのセキュリティの問題をあまり重要視していないんだろうね。彼らにとっては、次のハードウェア世代をできるだけ早く市場に出す方がずっと大事だと思う。つまり、ディストリビューションのメンテナーとハードウェアベンダーは、全然違うことに興味を持っていて、優先順位も全然違うってことだね。

それは、主にリーナスが作った組織のおかげだね(もちろん、参加している膨大な人数も)。ほんの少数の非常に影響力のある人たちが、ちゃんと仕事をするために大きな役割を果たしている。彼らが最高だという証拠は、ニュースに出てこないことだよ。ニュースにならないような影響力のある人がもっと必要だね。

OPの問題はWindowsに関係してるの?これがすぐにはわからなかったんだけど。

Linuxは1995年からカーネルモジュールの読み込みをサポートしてるよ。

Windowsでこれらのアップデーターを実行する必要はあまりないよ。

[遅延]

Ryzen Masterはドライバーじゃないよ。ほとんどの機能はLinuxでは使えないし、サードパーティのツールやドライバーを使っても無理だよ。

うわ、これはめちゃくちゃ深刻な脆弱性だね。MitMが必要だからって軽視してる人もいるけど、インターネット自体が基本的にMitMみたいなもんだから、常にMitMは存在するよ。

MitMすら必要ないよ、悪意のあるDNSを設定する不正なDHCPサーバーが攻撃することもできるからね。

タイトルから、これは修正がほぼ不可能な推測実行による情報漏洩バグの一つかと思ったけど、こんなにシンプルで簡単に修正できるものだとは…がっかりだね。できればこの決定が覆るといいな。それに、「私たちの製品をハッキングしてくれてありがとう」って、重大なセキュリティ問題について責任ある開示をしている人に対してはちょっとプロフェッショナルじゃない気がする。

もしこれが説明通りなら、セキュリティ脆弱性の報告の優先順位付けにかなりの失敗があるってことだね。大企業のセキュリティ部門が、AMDハードウェアを完全に禁止するか、AMDのアップデートアプリだけを禁止するか会議を開くレベルだよ。もし「ブランド名とスコア付きCVE」のルートを選んでたら、ニュースになってたかも。今からでもニュースになるかもしれないね。ここでの脅威モデルは、妥協されたり悪意のあるWi-Fiホットスポット(とISP)が存在して、すべての暗号化されていないトラフィックを監視し、実行可能ファイルをダウンロードしているものを探し、マルウェアを注入するってこと。これを実行するアップデーターを使っているマシンが妥協される可能性があるし、過去に多くのノートパソコンがすでに妥協されているだろうね。

この決定を合理化できる人いる?技術的には範囲外かもしれないけど、この脆弱性の深刻さはすぐにわかるはずで、範囲を再考する必要があるって警鐘が鳴るべきだよ。これでたった一人の顧客を失ったら、最低でも500ドルの報酬以上の損失になるんだから。彼らは、セキュリティを改善するよりも範囲の文書を重視しているって世界に示しているし、将来のハッカーが彼らのプログラムに関わるのを遠ざけることになるよ。技術的な理由で報酬を奪うビジネスケースって何なの?