The RCE that AMD wouldn't fix

Original Article ↗ Hacker News Discussion ↗

A remote code execution flaw in AMD’s Windows auto‑updater, caused by downloading updates over plain HTTP, has reignited criticism of the company’s software quality and security practices. Commenters argue that treating man‑in‑the‑middle attacks as “out of scope” for AMD’s bug bounty undermines both researcher incentives and user safety, especially given the slow response and initial refusal to address the issue. While AMD eventually switched the updater to HTTPS, the use of a non‑cryptographic CRC32 check instead of proper signing is seen as emblematic of a deeper, long‑standing neglect of robust software engineering at the company.

Vulnerability and Impact

  • AMD Windows utilities (e.g., Ryzen Master) shipped with an auto‑updater using plain HTTP to fetch update metadata and binaries.
  • This enables remote code execution via MITM or related attacks (e.g., DNS poisoning), though some note the updater was effectively half‑broken, which limits “mass” exploitation.
  • Several commenters stress that any vendor auto‑updater that can run code must treat the whole internet as hostile and protect against MITM.

Bug Bounty Scope and Incentives

  • AMD’s bounty vendor initially rejected the report as “out of scope” because MITM was excluded.
  • One side argues this is standard: bounties are narrow tools to direct internal engineering priorities, not comprehensive security programs, and companies are generally incentivized to pay.
  • Others argue “out of scope” is de facto “we don’t want to pay or fix this,” and external observers only see that serious bugs were ignored for months.
  • There is skepticism about assuming internal incentives are always aligned with paying bounties, citing corporate misaligned incentives in general.

AMD’s Fix and CRC32 “Signature”

  • AMD eventually switched the updater to HTTPS but reportedly “verifies” downloads only with CRC32.
  • Multiple commenters call this security‑illiterate: CRC32 detects accidental corruption, not malicious tampering, and is trivial to collide.
  • Some note that the real missing piece is code‑signing verification; in theory HTTPS plus proper signatures would be adequate.

Threat Models and MitM

  • Debate over excluding MITM from bounty scope: some defend it as limiting responsibility for the environment; others say MITM over HTTP with no cryptographic checks is obviously in scope.
  • Comparisons are made to excluding social engineering from bounties; critics say this is different because no human interaction is needed.

Broader AMD Software Critiques

  • Many comments describe AMD’s software and drivers as chronically poor: buggy utilities, bad fan curves, annoying pop‑ups, long‑standing GPU compute issues.
  • Complaints extend to ROCm, HIP, and dropped or weak OpenCL support, seen as self‑sabotage versus CUDA.
  • Some speculate about company culture undervaluing software and underpaying engineers.

Ethics, Disclosure, and Reactions

  • Several see this as evidence white‑hat work and bug bounties are increasingly thankless.
  • Some advocate full public disclosure sooner when vendors stall or hide behind scope rules.
  • A few propose crowd‑funding a “bounty” for the researcher.
  • Light speculation appears about possible state‑actor backdoors, but others attribute it to simple negligence.