← 返回日报
精读 预计 2 分钟

AMD Stiffs Researcher $10k Bug Bounty

摘要

研究员发现 AMD 的 Windows 自动更新程序(如 Ryzen Master)通过不安全的 HTTP 连接下载软件,存在中间人攻击(MitM)风险,可导致远程代码执行。AMD 在修复该漏洞过程中多次请求推迟披露,最终耗时 124 天才发布补丁,但以“政策排除中间人攻击”为由拒绝支付赏金。此外,补丁虽然启用了 HTTPS,但仍使用安全性较低的 CRC32 校验而非加密签名,底层安全性仍受质疑。

荐读理由

识别硬件大厂在工程安全上的具体疏漏(如 AMD 修复方案仍沿用极易伪造的 CRC32 校验而非加密签名),作为你评估底层系统组件安全性与供应商技术信誉的实据。

原文

Finding a critical security vulnerability should get you rewarded, not stiffed. AMD’s auto-updater was downloading software over insecure HTTP connections, letting network attackers slip malicious code onto your system during routine updates. The researcher who found this remote code execution flaw expected a $10,000 bounty. Instead, AMD fixed the problem after four months and paid nothing.

The Flaw That Could Own Your System

A trusted update process became an open highway for malware delivery.

Paul LaRosa discovered that AMD’s Windows auto-updater—used by Ryzen Master and other utilities—was grabbing updates through unencrypted HTTP connections. Anyone positioned on your network could perform a man-in-the-middle attack, swapping legitimate driver downloads with malware. Think of it like ordering food delivery but letting strangers intercept and replace your meal between the restaurant and your door. Your system would happily install whatever the attacker served up, believing it came from AMD.

This affects you if you’ve used AMD utilities that handle automatic updates. The vulnerability created a highway for attackers to achieve remote code execution, essentially gaining control of your machine through what should be a trusted update process.

Four Months of “Just a Little More Time”

What started as a 90-day disclosure window stretched into a four-month waiting game.

AMD acknowledged the flaw was real but refused the bounty, citing policy exclusions for man-in-the-middle attacks. The company asked LaRosa to delay public disclosure in February, promising a fix within 90 days—standard practice in security research. Then AMD asked for more time. Then more again. The final patch arrived 124 days after the initial report.

Compare that timeline to security best practices: critical vulnerabilities should be patched within 5-14 days, not over four months. It’s like your doctor finding cancer and scheduling treatment for next season. Some flaws demand urgency, especially those affecting automatic update mechanisms that users trust to keep them secure.

Still Using Weak Security After the “Fix”

The patch solved one problem but left deeper security weaknesses untouched.

AMD reengineered the auto-updater to use encrypted downloads, but the fix reveals deeper problems. The updated software still validates downloaded files using CRC32—a checksum that’s about as secure as a screen door. Modern software should use cryptographically signed updates that can’t be forged, not checksums that determined attackers can manipulate.

This case exposes how major vendors handle security: fix the immediate problem, avoid paying researchers through policy loopholes, and leave underlying weaknesses in place. You’re left wondering which other “secure” auto-updaters are similarly vulnerable, and whether companies care more about their bug bounty budget than your system security.

Hacker News · 10 赞 · 0 评 讨论 → 阅读原文 →

这条对你有帮助吗?