2026 年 2 月初，安全研究员 MrBruh 在其博客披露了一个存在于 AMD AutoUpdate 软件中的远程代码执行（RCE）漏洞。令人意外的是，AMD 安全团队在收到报告后数小时内，便以 “超出范围” 为由将其关闭，认定此问题 “无需修复”。这并非漏洞复杂到无法修补，而是一个源于基础安全实践缺失的配置错误：软件通过不安全的 HTTP 协议下载更新可执行文件，且 **“does no such validation and immediately executes the downloaded file”**（不进行任何验证便立即执行下载的文件）。当厂商选择不作为时，安全工程师的责任便是构建防御纵深。本文旨在深入剖析该漏洞的技术链条，并提供一个从网络隔离、主机加固到利用平台硬件特性的可落地缓解方案与参数清单。
漏洞技术剖析：一条清晰的攻防路径
该漏洞的触发条件看似简单，却构成了一条完整的攻击链。根据披露信息，AMD AutoUpdate 软件将其更新清单的 URL 硬编码在程序的app.config文件中。虽然初始请求使用 HTTPS，但其返回的 XML 清单中，可执行文件的下载链接均指向 HTTP 端点。这构成了第一个突破口：任何能够实施中间人（MITM）攻击的对手，都可以在用户网络层（如公共 Wi-Fi、被入侵的路由器或受控的 ISP 链路）拦截这些 HTTP 请求，并将其响应替换为任意恶意可执行文件。
关键的第二环在于软件完全缺乏对下载文件完整性与真实性的校验。研究员通过反编译代码确认，程序在下载文件后，没有检查数字签名、哈希值或任何证书绑定机制，便直接发起执行。这意味着攻击者注入的载荷会以与 AutoUpdate 服务相同的权限（通常是SYSTEM或高权限用户）在目标系统上运行，实现完全的远程代码执行。漏洞的影响范围覆盖所有预装了该软件的 Windows 系统，尤其在游戏 PC 和工作站中常见。
工程化缓解：从临时补丁到监控清单
在官方补丁缺位的情况下，防御必须依靠主动干预。以下方案按实施成本和复杂度递增排列，可组合使用。
1. 网络层封锁（最直接有效）
核心思路是阻断 AutoUpdate 软件与不安全更新服务器的通信。由于攻击依赖 HTTP 下载，阻止相关出站连接即可消除风险。
-
主机防火墙规则（Windows Defender Firewall）:
# 禁止AMD AutoUpdate相关进程对外发起HTTP（80端口）请求 New-NetFirewallRule -DisplayName "Block AMD AutoUpdate HTTP" -Direction Outbound -Program "C:\Program Files\AMD\AutoUpdate\*" -Protocol TCP -RemotePort 80 -Action Block -Enabled True此规则需根据软件实际安装路径调整。更激进的做法是直接阻止该进程的所有出站连接（
-RemotePort Any），但这可能影响其正常的 HTTPS 元数据检查功能。 -
网络设备策略: 在企业边界防火墙或 DNS 过滤设备上，解析并屏蔽 XML 清单中涉及的 HTTP 域名或 IP 地址。这需要定期从样本中提取这些地址并更新策略。
2. 主机行为限制
旨在增加攻击者利用漏洞的成本和被发现的可能性。
- 软件限制策略（SRP）或 AppLocker: 配置规则，禁止从 AutoUpdate 软件通常的临时下载目录（如
%TEMP%或C:\AMD\下的特定子目录）执行任何.exe或.msi文件。这能阻断恶意载荷的最终执行阶段。 - 权限降级: 通过服务管理器（
sc.exe）或组策略，将AMD AutoUpdate Service的运行账户从LocalSystem修改为权限更低的本地账户，并严格限制其目录写入与执行权限。
3. 监控与检测参数
建立监控以发现潜在的攻击尝试或异常行为。
- 关键进程监控: 监控
AMD AutoUpdate进程（如AMDAutoUpdate.exe）是否启动了任何新的子进程，尤其是从临时目录启动的未知子进程。这可以通过 Sysmon（Event ID 1）或 EDR 产品实现。 - 网络流量异常: 在 SIEM 中设置告警规则，侦测从内部主机向非常用外部 IP 地址（非 AMD 官方 CDN）发起的 HTTP（端口 80）连接尝试，特别是当 User-Agent 字符串包含 “AMD” 时。
- 文件系统监控: 监视 AutoUpdate 工作目录中是否突然出现了非 AMD 签名的可执行文件。Windows 安全审计事件（如 4663）或文件完整性监控（FIM）工具可用于此目的。
硬件安全特性的辅助角色
AMD 平台提供了一些硬件级安全功能，虽然不能直接修复此软件漏洞，但能提升系统的整体韧性，增加攻击复杂度。
- AMD Memory Guard: 对于搭载锐龙 PRO 或特定企业级处理器的系统，此功能可对系统内存进行透明加密。即便攻击者通过 RCE 漏洞注入代码并尝试扫描内存窃取敏感信息（如凭据），Memory Guard 能确保数据在离开 CPU 核心后即被加密，有效缓解此类内存爬取攻击。在 BIOS/UEFI 设置中启用此功能是推荐的基线安全配置。
- AMD-V (虚拟化技术) 与 SEV-SNP: 在虚拟化或机密计算场景中，SEV-SNP（安全加密虚拟化 - 安全嵌套分页）可以为虚拟机提供强大的内存隔离和完整性保护。虽然与桌面 AutoUpdate 漏洞无直接关联，但它体现了硬件在构建信任根和隔离不可信代码方面的价值。对于运行关键工作负载的 AMD 平台，评估并启用这些高级功能是纵深防御的一部分。
- 平台安全处理器（PSP）: PSP 是 AMD 平台上的信任根，管理安全启动等。确保系统启用并强制执行安全启动，可以防止攻击者在获得 RCE 权限后持久化植入 bootkit 等底层恶意软件。
结论：当供应链安全失效时
AMD AutoUpdate 漏洞事件是一个典型案例，揭示了软件供应链末梢的安全盲点 —— 一个本应通过强制 HTTPS 和代码签名即可预防的低级错误，因厂商的 “范围界定” 而被搁置。对于安全工程师而言，这强调了几个关键点：
首先，对闭源商业软件的盲目信任是危险的。即便像 AMD 这样的硬件巨头，其配套软件也可能存在基础安全缺陷。主动的资产清点（识别并评估所有预装和后台软件）与网络行为监控变得至关重要。
其次，缓解措施需要参数化和可操作。上文提供的防火墙规则、AppLocker 配置和监控指标，都是可以立即编码、部署和验证的具体参数。安全的价值在于将其转化为工程实践。
最后，硬件安全特性是重要的防御纵深，而非银弹。它们能够提高攻击门槛、限制损害范围，但不能替代对软件层漏洞的根本性修补。在等待（或不再期待）官方修复的同时，组合运用网络控制、主机加固、行为监控和硬件能力，是为系统构建弹性的务实之道。
资料来源：MrBruh. "The RCE that AMD won't fix!". https://mrbruh.com/amd (Accessed 2026-02-06).