ハクソク

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

AMDが修正しなかったRCE

2026年6月12日原文(mrbruh.com)

概要

  • AMD AutoUpdateソフトウェアに 重大なRCE脆弱性 を発見
  • HTTP通信 を利用したMITM攻撃のリスク
  • AMDの バグバウンティ規約 により報酬対象外とされる
  • 修正までに 124日 を要し、対応の遅れが問題に
  • 最終的に CVE発行・部分的な修正 が行われるも、完全な対策には課題

AMD AutoUpdateの脆弱性発見と経緯

  • 新しいゲーミングPCで 頻繁に表示されるコンソールウィンドウ の原因を調査
  • 該当プロセスが AMD AutoUpdate であることを特定
  • app.config 内にアップデートURLが記載されていることを発見
  • プロダクション環境で "Development" URL が使われている点が不自然
  • アップデート情報XMLは HTTPS で配信されているが、実際の実行ファイルのダウンロードURLは HTTP を利用
  • MITM攻撃 による悪意ある実行ファイル配信リスク
  • 署名チェックや証明書検証なし で即時実行される設計

AMDへの報告と対応

  • AMDの バグバウンティ規約 ではMITM関連は「対象外」とされ、最初は 受付拒否
  • Hacker Newsで話題となり、 AMD PSIRT が再調査を開始
  • 第三者プラットフォームIntigriti は初期トリアージを担当
  • AMDは 記事の一時公開停止 と 長期エンバーゴ を要請
  • 修正内容の連絡や進捗更新が遅く、 合計124日 の公開延期
  • 複数のオプションツール に影響が及ぶため、追加の調査・修正が必要と説明

修正内容とその評価

  • 最終的な修正として、 Ryzen Master のオートアップデーター機能をインストーラーからアプリケーション層へ移動
  • 全通信をHTTPS化 し、アップデートファイルに 署名検証 を導入したと説明
  • 実際には CRC-32チェックのみ で、 暗号学的な安全性は不十分
  • アップデーターの リダイレクトバグ により、そもそも脆弱性が発動しない状況も発生

公開・報酬・今後の注意点

  • バグバウンティ報酬はゼロ （他社も含めて累計$0）
  • 本件は CVE発行・研究者クレジットのみ で金銭的報酬なし
  • エンバーゴ期間 の不透明さと、 修正の遅さ が課題
  • AMDユーザーには ソフトの完全アンインストールと最新版導入 を推奨

タイムライン（DD/MM/YYYY）

  • 27/01/2026 - 脆弱性発見
  • 06/02/2026 - AMDへ報告、即日「対象外」対応
  • 06/02/2026 - ブログ初公開
  • 07/02/2026 - AMDが再調査を表明
  • 09/06/2026 - エンバーゴ解除（124日経過）

関連リンク

まとめ

  • バグ報告と脆弱性公開 のプロセスの透明性・迅速性の重要性
  • HTTP通信 や 署名未検証 は重大なリスク要因
  • 責任ある開示 と ユーザー保護 のバランスの難しさ
  • 今後も ベンダーの対応姿勢 や セキュリティ慣行 への注視が必要

Hackerたちの意見

動画が言及している議論について [1] [1] - https://news.ycombinator.com/item?id=46906947

└

元の投稿 [1] に更新が追加されたよ：更新！Hacker Newsでこの話が盛り上がってから1日以内に、AMDが再度連絡をくれて、結局この件を調査することになったって。 [1] https://mrbruh.com/amd2/

AMDはそれが脆弱性であることを否定してはいない。ただ、バウンティプログラムの範囲には入っていないと否定したんだ。大手テック企業では、バウンティを支払うインセンティブがあるから、プログラムの支払い額によってパフォーマンスが評価される人たちがいるんだよね。

└

何をそんなに細かく分けてるの？問題は、AMDが顧客のシステム内に既知の深刻なセキュリティ脆弱性を数ヶ月も放置して、しかもそれについて誠実さを欠いた行動を取ったことなんだよ。

└

彼らはこれを静かにしておきたかったんだ。国際ネットワークリンクにアクセスできる人たちに利用されても構わないかのように。

MITM攻撃がコンピュータを乗っ取ることに関して範囲外だと考えるのは馬鹿げてる。実際、DNSキャッシュポイズニングのように、真のMITMなしでこれを悪用する方法もあるだろうけど、全インターネットがMITMされていると考えるのが一番いいよ。

└

範囲外だからといって、影響がないわけじゃない。企業が自社のソフトウェアが動く環境にどれだけ責任を持ちたいかの問題なんだ。ほとんどの場合、その答えは「あまり持ちたくない」ってことだね。

└

でも、Wi-Fiパスワード使ってるから、俺のスマホは安全って言ってるよ！

└

MITMで攻撃者が被害者のデバイスに自分のCA証明書をインストールする必要があるなら、確かに範囲外だね。httpを使ったせいでMITMになって、データに他の検証済みの暗号署名がないなら、さっさと直せよ。

└

この場合の「範囲外」っていうのは、「お金払いたくない」ってことだね。

└

なんで誰も真のMITMを除外するの？いろんなドメインレジストラが何度も侵害されてる（しばしば子供たちによって！）、その結果、テスラやクラウドフレアがやられちゃった。実際、ちょっとでも能力のある攻撃者なら、裁判所の事務員を侵害して、例えば.comレジストリに好きなドメインを渡させることができる。前述の問題はDNSを超えた大きな影響があると思うけど…。

└

「あなたのコンピュータを乗っ取ること」に関しては範囲外じゃないよ。バグバウンティプログラムの具体的な目標に対しては範囲外ってこと。バグバウンティは（通常）内部のエンジニアリング努力を優先するためのもので、脆弱性の修正に関しては、製品の他の機能や決定に対する市場のフィードバックと同じ。みんな「どれだけ良いバグか」で判断してるけど、それがバグバウンティの機能の仕方じゃないかもしれない。重要なのは、個々のバグバウンティの提出や、すべての有効な提出の合計が、真剣な製品のセキュリティを実質的に変えることはないってこと。彼らが提供するシステム（例えば、セキュリティエンジニアが検証されたバウンティ提出を受けて、同じバグのバリエーションをすぐに監査すること）は、ダイヤルを動かすことができるけど、バウンティバグ自体はほとんどサイドショーだよ。特に変なのは（君は言ってないけど、この話に関する3つのスレッドでこの感情が出てきてる）、AMDがこれを隠そうとしているという考え。なんで彼らが気にするの？バグバウンティプログラムを運営してるんだから。彼らは脆弱性があるという前提を受け入れてるんだよ。（今日の早い時間に、追加で： https://news.ycombinator.com/item?id=48492908）

Hacker Newsで議論の続きを見る