One-Click RCE in Asus's Preinstalled Driver Software

Reaction to the ASUS Vulnerability & Bug Bounty Policy

• Many commenters are appalled that ASUS offers no monetary bug bounty, only a “hall of fame” mention, despite being a large, well‑established company.
• Several say this alone is enough to avoid ASUS products going forward; others generalize to “don’t buy from vendors that don’t pay for security.”
• Some argue that if companies won’t pay, researchers are incentivized to sell exploits on the black market or disclose publicly to force action.

ASUS Reputation, Devices, and Trust

• Multiple stories describe long‑standing frustration with ASUS software, bloatware, and security incidents, including past UEFI‑related issues.
• Users complain about deceptive or broken promises (e.g., Zenfone bootloader unlock tools, short update lifecycles), leading to feelings of “not your device, the manufacturer controls it.”
• A few defend ASUS’s response time on this specific issue, noting they didn’t threaten the researcher and patched relatively quickly, but others point out their downplaying language and pattern of behavior.

Responsible Disclosure vs Immediate Public Disclosure

• Long, heated debate on whether “responsible (vendor‑coordinated) disclosure” is itself irresponsible.
• One camp: private, time‑boxed disclosure minimizes mass exploitation by script‑kiddies and opportunistic attackers, and allows coordinated patches; researchers should give vendors at least days to weeks, with flexibility for very hard bugs.
• Opposing camp: corporations routinely delay, hide, or spin vulnerabilities; immediate or very fast public disclosure is needed to inform users, apply pressure, and change incentives. They frame current norms as protecting corporate reputations over users.
• Middle‑ground views suggest shorter default windows, stricter treatment of repeat‑offender vendors, and different standards for hobby open‑source vs mega‑corps.

Regulation, Liability, and EU Rules

• Many argue the core problem is lack of software liability; they favor treating software more like cars or food: recalls, refunds, mandatory long‑term security support.
• EU’s Cyber Resilience Act and related regulations are cited as promising: products with known exploitable vulnerabilities may become unsellable; manufacturers must provide update paths.
• Some worry about bureaucracy and enforcement complexity; others note similar recall systems already work for food.

Driver Tools, Bloatware, and Hardware Vendor Software

• Broad consensus that OEM driver updaters and control panels (ASUS, Gigabyte, AMD, laptop vendors, SSD tools, etc.) are “trash”: insecure, bloated, slow, privacy‑invasive, and often break things.
• Several users now avoid vendor tools entirely, preferring Windows Update or Linux’s in‑kernel driver model and projects like fwupd.
• Some describe reverse‑engineering vendor utilities and replacing them with simple open‑source tools that just talk to the hardware.

Motherboard Choices and Open Hardware

• People ask which motherboard brands are “basically respectable”; answers suggest all major consumer brands have serious issues (security, firmware quality, UX).
• There’s interest in open‑hardware motherboards, but commenters note x86 boards effectively require Intel’s blessing; RISC‑V is mentioned as a more realistic long‑term path.

Technical Side Notes (Exploitability & Detection)

• Discussion on using certificate transparency logs to detect prior exploitation via subdomain takeover: works for explicit driverhub.asus.com certs, but wildcards and internal CAs can be blind spots.
• Some note further ambiguity: self‑signed certs and non‑HTTPS traffic wouldn’t show in CT logs.