Bluetooth keystroke-injection in Android, Linux, macOS and iOS

Original Article ↗ Hacker News Discussion ↗

Bluetooth implementations in Android, Linux, macOS and iOS contain a keystroke‑injection vulnerability (CVE-2023-45866) that allows an attacker nearby to spoof a keyboard and send commands without user confirmation, in some cases even when a device only has Bluetooth enabled. Commenters examine how different stacks ended up exposed — from insecure or backwards‑compatibility‑driven defaults in Linux’s BlueZ to Apple’s “magic” auto‑pairing behavior — and note that recent OS updates fix the issue on many platforms, though older Apple systems remain unpatched. Practical mitigation ranges from disabling Bluetooth or tightening configuration (e.g., BlueZ’s `ClassicBondedOnly=true`) to favoring wired peripherals, while questions remain about Windows’ exposure and the broader trade-off between wireless convenience and security.

Scope of the Vulnerability

  • CVE-2023-45866 allows Bluetooth devices to impersonate keyboards and inject keystrokes by abusing “unauthenticated” pairing behavior in the Bluetooth spec plus implementation bugs.
  • Attack can work without user confirmation and, in some cases, without an existing trusted keyboard being active.
  • Practical impact: launching terminals, installing software (where no extra auth), dialing numbers, or triggering nuisance actions; more severe attacks may require chaining with other vulns.

Platform-Specific Notes

  • Android
    • Described as “a field day”: vulnerable whenever Bluetooth is enabled, not just when discoverable.
    • December 2023 Android security bulletin includes a fix; some derivatives (e.g., DivestOS) also backported patches to older versions.
  • Linux / BlueZ
    • The underlying issue was patched in 2020 but shipped disabled (“insecure default”) for compatibility with older devices.
    • Mitigation is a config flag ClassicBondedOnly=true; some distros and ChromeOS now enable it by default.
  • macOS / iOS
    • Vulnerable when Bluetooth is enabled and a Magic Keyboard has been paired.
    • Fixed in current versions (macOS 14.2, iOS 17.2), but not backported to macOS 13 / iOS 16, which frustrates users relying on “supported” older devices.
    • Details of how “Magic Keyboard” pairing is abused remain unclear; questions about whether mere historical pairing is enough.
  • Windows
    • Not mentioned in the write-up; unclear whether it is unaffected or just untested. Some want architectural details; others note separate HID-style attacks exist via other tools.

Mitigations & Practicality

  • Common advice:
    • Disable Bluetooth when not needed (hard or non-persistent on iOS/macOS; easy on Android).
    • On Linux, explicitly set ClassicBondedOnly=true and restart Bluetooth.
  • Some argue risk is lower on locked phones or where app installs require biometrics/passwords; others note many devices sit unlocked or wake easily.
  • Kiosks and unattended machines are seen as especially exposed.

Security vs Usability / Wireless vs Wired

  • Strong theme of “convenience/backward compatibility vs security,” with criticism of insecure defaults and automatic pairing behaviors.
  • Debate over Bluetooth in general: viewed by many as fragile and insecure compared to wired; others report stable, low-latency experience with modern hardware.
  • Several participants reaffirm preference for wired keyboards for both reliability and security, though others prioritize ergonomics and aesthetics of wireless setups.