Critical Exploit in MediaTek Wi-Fi Chipsets: Zero-Click Vulnerability

Original Article ↗ Hacker News Discussion ↗

A newly detailed zero‑click vulnerability (CVE‑2024‑20017) in MediaTek Wi‑Fi chipsets stems from `wappd`, a vendor SDK daemon used with certain MT76xx/MT79xx chips, raising concerns about whether affected products are widespread and how easily such flaws could resemble intentional backdoors. Commenters note that upstream OpenWrt and many major vendors may not actually ship this component, but that OEM-customized “OpenWrt-based” firmware and proprietary driver bundles are harder to audit. The incident fuels broader criticism of rushed, low-cost Wi‑Fi firmware development, the reluctance to open‑source radio stacks due to regulatory and competitive pressures, and the uneven reliability of different silicon vendors’ networking solutions.

Nature of the vulnerability / backdoor debate

  • Some argue the exploit is indistinguishable from a backdoor in practice.
  • Others caution against assuming intent, suggesting it’s more likely incompetence but that nation‑state actors probably know and exploit such bugs.
  • One comment notes that if a state actor wanted a backdoor, they’d design it to look like incompetence anyway.

Where the bug actually lives (SDK vs baseband / OpenWrt)

  • The flaw is in wappd, part of MediaTek’s Wi‑Fi SDK / SoftAP driver bundle, not in the baseband or the mainline mt76 driver.
  • This is described as “vendor shovelware” / value‑add services rather than core chipset functionality.
  • Multiple comments point out confusion around claims that OpenWrt 19.07/21.02 are affected.
    • Upstream OpenWrt reportedly does not ship wappd; the mention likely refers to vendor-modified OpenWrt images.
    • No OpenWrt security advisory exists for this, which some find telling.
  • Some vendors (e.g., Ubiquiti) are said to have vulnerable driver bundles in SDKs but claim no shipping products use them.

Firmware quality, economics, and vendor SDKs

  • Many describe MediaTek vendor code as messy and “PoC‑like,” contrasting it with the cleaner mt76 driver.
  • Broader theme: hardware companies are often weak at software; firmware is rushed to meet silicon ship dates under razor‑thin margins.
  • There’s frustration that consumer competition favors lowest cost and latest features over robust firmware.
  • Some praise open drivers (mt76, ath9k) and criticize vendor SDKs, but note vendors feel pressured not to open too much due to competition.

Open source firmware vs regulation (FCC)

  • One side argues radio vendors could “go PC-style” and fully open firmware, leveraging community fixes.
  • Others counter that FCC rules require preventing non‑compliant radio behavior, often leading to locked firmware.
  • Debate ensues over whether this is a real or overstated constraint and whether hardware alone should enforce region/power limits.

Impact on real devices and user experience

  • Several participants verify that clean upstream OpenWrt on common routers should be unaffected.
  • Confusion remains around vendor-forked “OpenWrt-based” firmware; those are considered “unclear / all bets off.”
  • Laptop Wi‑Fi card anecdotes:
    • MediaTek RZ616 / MT79xx are widely disliked by some (slow connects, sleep issues on Windows).
    • Others report better stability with MediaTek than Intel under Linux, indicating highly variable real‑world behavior.
    • Qualcomm is used as an alternative by some OEMs but criticized for weak long‑term mainline support.

Meta: source choice and security culture

  • Some want HN submissions to link directly to the original technical blog, others prefer concise overviews, especially for quick impact assessment.
  • Broader lament that overall incentives for secure coding are poor; even “safer” languages and runtimes can be undermined by ecosystem and human factors.
  • Calls for more free/open firmware and less dependence on opaque Broadcom/MediaTek/Ralink blobs.