AMD AutoUpdate 遠端程式碼執行漏洞

漏洞摘要

AMD 的 AutoUpdate 軟體包含一個關鍵的遠端程式碼執行 (RCE) 漏洞，允許中間人 (MITM) 攻擊者將合法的軟體更新替換為惡意可執行檔。該漏洞存在的原因是軟體透過 HTTPS 下載更新資訊清單，但卻透過未加密的 HTTP 取得實際的可執行檔，且未對下載的檔案進行任何加密簽章驗證。

技術根本原因

該漏洞源於未能保護軟體更新的端到端傳遞鏈。儘管初始更新 URL 在 app.config 檔案中使用 HTTPS，但產生的 XML 資訊清單包含使用純 HTTP 的可執行檔下載連結。

因為 AutoUpdate 軟體未驗證下載的可執行檔的數位簽章，它會立即執行從 HTTP URL 接收到的任何檔案。這使得任何具有網路存取權的攻擊者——例如本地網路上的惡意行為者或 ISP 級別的實體——能夠攔截 HTTP 請求並提供惡意載荷，而非官方的 AMD 更新。

披露時間線與回應

報告和修補此漏洞的過程持續了 124 天，期間研究人員與 AMD 安全團隊之間存在顯著的摩擦。

• 探索與初始報告: 該漏洞於 2026 年 2 月 6 日被發現並報告。
• 初始拒絕: AMD 的第三方漏洞賞金平台 Intigriti 初始將該報告標記為「超出範圍」，理由是根據其當前指南，中間人攻擊不符合賞金資格。
• 反轉: 在研究人員發表部落格文章且該問題在 Hacker News 上獲得關注後，AMD 內部的產品安全事件響應團隊 (PSIRT) 重新開啟了該案件。
• 禁令與延遲: AMD 要求研究人員移除部落格文章，並請求延長超過業界標準 90 天的禁令期間，聲稱除了 Ryzen Master 之外的多種工具也受到影響。
• 解決: 禁令於 2026 年 6 月 9 日結束，這是初次披露後的第 124 天。

修補程式與剩餘的安全缺口

AMD 的最終修復涉及將自動更新功能從安裝程式移至應用層，並將所有更新通訊過渡到 HTTPS。

然而，研究人員發現 AMD 說明其實施「簽章驗證」的主張不正確。AMD 沒有使用加密安全的簽章，而是實施了 CRC-32 檢查。正如在 Hacker News 討論中所指出的：

"『簽章驗證』在修補中使用 CRC-32 實在令人啼笑皆非。"

因為 CRC-32 是一種錯誤偵測碼，而非加密雜湊或簽章，它無法防禦故意的竄改。如果網頁伺服器被入侵，攻擊者只需計算惡意檔案的 CRC-32 並更新資訊清單，就能使感染變得微不足道。

意外的緩解措施

有趣的是，有證據顯示，由於另一個軟體錯誤，此漏洞在某些版本中可能意外地無法被利用。AMD 將其託管從 ati.com 遷移至 drivers.amd.com，但據報導，AutoUpdater 程式無法處理由此產生的 HTTP 程式無法處理由此產生的 HTTP 重新導向。這導致程式在到達負責下載不安全 HTTP 可執行檔的程式碼之前就當機或卡住，形成一種「Catch-22」：更新程式太破損而無法被利用，但同時也太破損而無法獲得安全修復的更新。