Bluetooth keystroke-injection in Android, Linux, macOS and iOS
github.com
github.com
Android: disable Bluetooth when you're not using it (but you'll be vulnerable while you are). My Pixel just got the 12/5/2023 security update, which fixes the issue; not sure about non-Pixel phones.
Linux: Open up /etc/bluetooth/input.conf and set ClassicBondedOnly=true (in my case I just had to uncomment this, not add anything). The next version of bluetoothd should default to =true, but you can set this yourself now. Don't forget to restart the bluetooth service after doing so.
Not sure about macOS or iOS; I don't have devices running either of those.
I used to make the effort when I switched from Android, but I already gave up...
You are sacrificing your battery life (and I guess privacy and security) for the ecosystem to work.
Apples official stance is that this behavior “functions as intended”.
Depending on whether you have the Settings icon on your Home Screen, that’s three taps (Settings -> Bluetooth -> Off). Not even any scrolling.
Annoyingly so it doesn't even always open on the expected screen, e.g. when opening "Wifi settings" from the network selection you might end up in notifications if it was the last screen you used. Not a consistent bug.
I’m adding a new action, I search toggle and Bluetooth and I’m not getting any actions to set Bluetooth. What am I doing wrong? Edit: Scratch that! I figured it out! Realised I wanted a way to connect to a Bluetooth device (my flaky headphones don’t always connect, pain to dig into the settings every time)
AirPods can stay connected, which is maybe unfair towards third-party vendors, but they also don't insist on connecting to all paired devices at once and usually pick the two wrong ones and steal audio from whoever in my home is using that device at the moment.
It is not permanent and comes back when disabling airplane mode, in addition to updates too.
Page says it only works for stuff that doesn't require password or biometrics.
I actively lock my phone when not using it, and surely I'd see the activity of the keystrokes being sent when using my device, no?
In that case it doesn't seem that horrible to leave Bluetooth enabled.
That was my first thought as well. Then I remembered how much time my device spends in my pocket or on my nightstand
$ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
* Thu Dec 07 2023 Peter Robinson <pbrobinson@fedoraproject.org> - 5.70-4
- Add mitigation for CVE-2023-45866 # Defaults to true for security.
#ClassicBondedOnly=true
# Set idle timeout (in minutes) before the connection will
# be disconnect (defaults to 0 for no timeout)
#IdleTimeout=30also, the emmentaler like wifi cannot be fully turned off from the control panel either
The control panel only disables WiFi until the next day.
# Defaults to true for security. #ClassicBondedOnly=true
macOS: https://support.apple.com/en-us/HT214035
Both say:
> Impact: An attacker in a privileged network position may be able to inject keystrokes by spoofing a keyboard Description: The issue was addressed with improved checks.
As someone with bluetooth devices (Smartwatch, buds, headphones, glasses etc) this is...difficult lol
That sounds great on the surface, but it would be really helpful to understand why Windows is not actually at fault so I can better measure the risk profile.
For example, knowing that the Windows Bluetooth stack has the architectural equivalent of BlueZ's `ClassicBondedOnly=false` would be really helpful to know; that would tell me to keep an eye out for it being `true` in environments I'm trying to harden, for example.
Alternatively the stack might work entirely differently and the status quo might consist of a different set of considerations to keep in mind.
This is awesome and I'm looking forward to the PoCs and (pleeease) video with lots of demonstrations :)
But Windows has enough market share and enough sysadmins are going to be going "!!!...???" that some info would be helpful.
That info might be "I haven't attacked Windows yet". That would be good to know too :)
If you look at the linux patch[1] it's a case of bad defaults. So maybe Windows just has good defaults?
[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
And Bluetooth got quite a bit better on Windows 11 after the new audio profile thing is available
The only issues I have are Bluetooth disappears after wake from sleep which after research appears to be due to buggy firmware of the Mediatek network card installed in the laptop and not due to Windows, as the same issue happens at wake from sleep in Ubuntu.
And another issue was due to the device used being a Chinese no-name bootleg e-waste piece of crap off Amazon. Ironically never had any issues with Bluetooth earphones off AliExpress.
So YMMV.
My Xbox Series controller is the biggest issue. For instance will not automatically reconnect when I pair it the first time and then disconnect. On the next turn on of the controller, it never finds the PC and connects. Windows then has no push for me to press to connect.
I have to delete the controller and then repair it each time. Sometimes I can’t even delete it and have to go into RegEdit and delete it. The delete button just does nothing sometimes in that menu
There are a lot of short straws you can pull in the Bluetooth stack lottery that don't necessarily stem from the OS.
I'd be interested in knowing what version of Windows you're using. Bluetooth has had a lot of updates in the past few generations of Windows.
This isn’t enough to tell you it’s not the hardware: you’d still need to check that it’s not, say, Linux being more tolerant of errors or not supporting a particular feature that the other stack is using. I know at least one person who had some long rant like that about audio, and then updated their Linux distribution to find that the newer bluez failed the same way.
Linux was running on the same hardware that windows was because I wanted to utilize my 4090 for some machine learning projects, so yes, there was an apples to apples comparison
(But yes, I always have issues with Bluetooth on Windows too)
All of my coworkers have issues with anything regarding Bluetooth on Windows too
But, with my Flipper Zero I can create a bluetooth device and as soon as a Windows client connects it will think it’s a keyboard and fire whatever powershell commands I want.. I have only used it to do a RickRoll myself (spawning Youtube), ai haven’t tried anything illegal with it.
Now I have all of my bluetooth disabled. But, I don’t know how to remove bluez without breaking linux.
Did you mean “ClassicBondedOnly=true”?
[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
I recognize that there’s still wired audio connectors but you know full well that the experience is not great because the industry wanted to remove audio jacks.
Not everyone wants to use a USB-C dongle so they can use their old 3.5 headphones, and even more people don’t really care about being able to have a mouse and keyboard on their phone in the first place.
If you want me to show you what the “thoughtful discussion” is: The parent made the point that phone companies have been following a trend of locking down physical access in favor of wireless tech. I’ll add that this has not only removed beloved features, but now that everyone is being forced down the Bluetooth/wifi stack we are far more susceptible in public when exploits like these rear their ugly heads. There are roundabout solutions like using a USB-C dongle but… really? Does anyone find that to be effective at all? What about when you want more than one connection? You need a splitter or a hub. It’s just such a seemingly useless “improvement” if it feels like we’re going backwards having to buy extra stuff.
If you want to reply with your disagreement, please do so in a thoughtful manner. Please think before you post. I come to this website not for snark, but for thoughtful conversation ;) Ty
There was no reason to remove it in the first place.
Why would you want to pair silently? Could someone provide more details on the intended purpose of the faulty mechanism?
On the devices affected? Who knows
[1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...
Oh yeah, intimidation is a strong basis for that myth that somewhere up high in the complex tech stacks there are people who know what they're doing and don't use sticks to prop up the castles built on quicksand
In targeted cases it might be enough to send a shift key-press every minute to avoid a screen lock kicking in so you can approach the machine yourself later and "do something".
https://mitxela.com/projects/smsc this cool project from yesterday he was able to use on his phone that way.
BTW. physical port charging only ports do exist.. Still wouldn't trust 'em w/ random cables though. Other end might deliver too much power if nothing else.
Also, what do they even mean, if the distro announcement says to simply upgrade to fix it[2]? Do they mean that even after the upgrade you need to manually change a setting? Because the NixOS fix seems to be simply to flip the default setting. If they mean that users which have explicitly set ClassicBondedOnly=false need to change it, that could've been a lot clearer.
[1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
Yes, that’s what “the fix was left disabled by default” would mean.
It’s good that it’s fixed by default now, but now is not 2020.
$ git log --grep=CVE-2023-45866 origin/nixos-23.11
$ git log --grep=CVE-2023-45866 origin/staging-23.11 ^origin/nixos-23.11
commit 8ba508ba10d27f61fe9f40eb8513d8d0864fbe14
Merge: f5cf92f30bd7 8fb1486901a3
Author: Martin Weinelt <hexa@darmstadt.ccc.de>
Date: 2023-12-11 13:02:10 +0100
Merge pull request #272751 from leona-ya/backport-272672-to-staging-23.11
[Backport staging-23.11] bluez: apply patch for CVE-2023-45866
commit 8fb1486901a3f4e7cbdee5616f7d1a39a5dc7a99
Author: Leona Maroni <dev@leona.is>
Date: 2023-12-07 13:44:59 +0100
bluez: apply patch for CVE-2023-45866
(cherry picked from commit 7d7f66dfba9f239f15aaec6512afb3443bbae915)Can Bluetooth HID be disabled without disabling e.g. audio devices (breasts).
Looks like this has just been fixed in iOS/macOS.
Or, if no usability is lost, then maybe the hypothesis isn't correct.
Considering the amount of time they took to release this, I assume they figured out a way to get it to work in those various cases after a lot of engineering effort.
I don't generally use Bluetooth devices in my house. Between the security nightmare aspect and the fact that it's always a worse end user experience than just going wired (no dropped packets, no failure to pair after being paired fine for months, no batteries slowly dying and then becoming spicy pillows; just 100% pure glorious wire).
Yes, I’m bitter. Somehow the video and touch are lag-free 1 but the audio is on a delay. I’d love to have regular Bluetooth audio be used.
Choosing to buffer for 3 seconds isn't the fault of wifi. There is no reason it couldn't start playing in a few milliseconds.
AirPlay 1 has this delay (or more like 2 seconds to be fair), while it is reduced to like 200ms on AirPlay 2.
shairport-sync runs on a raspberry AND supports airplay 2. You can hook it up to your car.
Proper hardware isolation (e.g. using IOMMUs) should be able to mitigate many of the resulting problems – and if the OS can be compromised using the software driver stack, that is indeed a problem of the OS/driver.
I guess I could maybe -- maybe -- see the convenience if you have some sort of small-form-factor keyboard that you stash in your bag. But still, the wire doesn't seem like much of a burden, and personally I'd find the annoyance of needing to ensure the batteries are charged/fresh to be... more annoying.
I can kinda see how a wireless mouse would be nice; the wire can get in the way of mousing around sometimes. But I'd still rather a wired one than wireless.
Charging is not an issue, get some Logitech that lasts months if not years.
Keyboards are used to enter secrets so they rank pretty high in my threat model.
And aesthetics? This is a forum that tirelessly obsesses over micro usb vs usb-c. Wired is de facto obsolete afaiac.
You could carry around a portable display, but that might be a bit of an overkill in terms of cost and bulk. Unlike a display, a portable keyboard is lighter and often smaller than the laptop itself. Modern wireless keyboards have almost no lag, have nice mechanical keys with replaceable keycaps, etc.
Working away from a stationary setup, I consider a separate keyboard a must—and particularly a wireless keyboard, since the one thing that reliably breaks on every laptop is physical I/O, especially USB/USB-C ports (and every time plugging/unplugging another accessory brings that closer).
Working with a stationary setup you have a detached keyboard anyway, and if it’s wired you don’t really need to unplug it, like, ever, so a wireless keyboard loses a lot of its advantages—though if you have a really large screen and have a lot of leeway for moving your chair around for comfortable work not having cables get in the way might be nice as well.
The most flaky removable thing I've encountered is microSD cards, and I don't know if it's the card or the reader, but they tend to only work half the time. I even check them for authenticity of space, so I don't know why they're so flaky.
Is it easy to source replacement I/O boards for Framework?
But on the original topic, it appears that modern wireless keyboards fare well enough as far as connection and latency[0] to qualify for gaming, so I wonder if your impression about connection reliability could be a bit outdated?
[0] https://www.rtings.com/keyboard/reviews/logitech/g715#test_6...
Anecdotally, I don’t tend to run into connection issues with wireless keyboards—I do with wireless mice, however.
Luckily, in USB-C, the springy bit is in the cable, so that's where the wear and tear is. If it stops working, the cable is generally easy to replace.
> I touch the chassis with my thumb and index finger around the USB, and kind of roll my fingers so they put pressure against the chassis
This doesn’t work when you have two ports in close proximity and one of them is occupied. In that scenario I’d have to either lift the laptop in order to squeeze the connector from top & bottom while removing (this option requires not being exhausted or lazy) or pull on a cable a bit further away from the connector (though I do it gently nowadays, pushing with another finger against the chassis for at least some balance).
They all is USB-C charged so I use a single charger cable for macbook, gaming controller, keyboard and mouse.
In that case, you likely want a wireless keyboard and mouse to use it.
Yes, absolutely. Having your keyboard right next to your screen is terrible ergonomics. Fine in a pinch or during a meeting, but not for working for hours.
The Magic Keyboard slides right into my bag, and I use it on my lap while my laptop sits on a table or airplane tray. It's incredibly more comfortable. I have long arms and it's literally impossible to type on a plane otherwise, without elbowing seatmates in the ribs. If I'm working somewhere remote that's more private, I use a tiny collapsible stand that raises the laptop display closer to eye height as well. (Don't want to attract weird attention like that in a coffee shop though.)
A surprising amount of keyboard shortcuts work on android, Alt+Tab works to get Recent Activities, Directional keys let you move aroud elements, even the special keys like home/calculator work
But there's a lot of unintuitive stuff, back button is Windows + Del
Obligatory https://xkcd.com/1200/
Running code works fine without root, at least to copy your emails, saved logins, and browser sessions file and such
Same idea - pretend you are a Bluetooth keyboard and send keystrokes at superhuman speeds.
This exploits the auto connect to special keyboard aspect of most OSs.
I’d really love more details on this, especially given the Magic Keyboard pairing requirement. Surely they can disclose the exploit now that it’s been fixed?
> Lockdown Mode does not prevent the attack
That is disappointing.
Do I understand this correctly that the attack requires a vulnerable keyboard to be actively connected to the device? But the fix for the vulnerability is on the device side, not the keyboard side?
Secondly, it’s still not clear to me how a “secure” keyboard would solve the problem if the vulnerability is on the device side (which it seems to be given that it can be fixed there).
I didn't really try to figure it out, but I expect paired in the sense of paired, not connected. Sounds like ios toggles a setting for HID when you pair the magic keyboard an becomes vulnerable to this.
The issues here appear to just be bugs.
That’s the BlueZ vulnerability. Which is certainly different from the iOS/macOS vulnerability given Apple has their own BT stack.
The decision made by the Linux kernel developers and distribution maintainers not to enable the fix by default is theirs. It doesn’t imply anything about Apple’s behavior.
If Apple wasn’t aware of this, they couldn’t have made a security/convenience decision at all.
Without knowing more it seems like jumping to conclusions. The Linux maintainers may have made a reasonable decision based on possible fallout from breaking lots of devices.
The Android vulnerability merely requires that Bluetooth be enabled, and it seems that's the case for macOS/iOS as well?
And fortunately the Linux/BlueZ issue doesn't even require a patch to fix; you can just change a boolean in a config file and restart the daemon. I never thought I'd be praising BlueZ for something, but I suppose there's a first time for everything.
diff --git a/profiles/input/input.conf b/profiles/input/input.conf
index 4c70bc561f..d8645f3dd6 100644
--- a/profiles/input/input.conf
+++ b/profiles/input/input.conf
@@ -17,7 +17,7 @@
# platforms may want to make sure that input connections only come from bonded
# device connections. Several older mice have been known for not supporting
# pairing/encryption.
-# Defaults to false to maximize device compatibility.
+# Defaults to true for security.
#ClassicBondedOnly=true
# LE upgrade securityExperiment flags should have a timer to auto-flip them after a few months...
For starters, enabling things can as easily introduce vulnerabilities as keeping them disabled. So you won nothing, created more pressure and have everyone working on top of a system that can change under their feet — a recipe for a disaster.
A small detail, though, the target device has to accept the connection. Once someone lets you in his house, you can steal his silver, yes.
however, it also mentions > stay tuned for Part 2: More Vulnerabilities
so I guess we'll see
Or to put it another way... who cares about that when the adversary is in position to just do a snatch and grab of the whole device?
Once again ChromeOS is showing it cares about security more than seemingly any other end user OS. I think it's really underestimated as a platform.
https://hntelegraph.com/post/bluetooth-keystroke-injection-v...
Good thing PC peripherals moved away from this junk. It was fascinating watching Logitech sell 300 euro BT keyboard with literally a second of lag, or "high end" mice with 500ms or more.
Hell, I barely use my PS5 controller because it sucks ass compared to my old Xbox 360 pad. Lag, lag, lag. 8 guess the majority does not notice or care, though.
The 5ms I referred to was the difference versus a cable - I’d expect a modern keyboard to be under 10ms and Bluetooth to be under 15ms. Since I’ve measured that the latency for a keystroke to render on screen in VSC at 16-24ms, I’m comfortable saying at least Apple has Bluetooth latency under that level.
And I believe these were patched in the current versions of iOS and macOS.
As someone who has bought multiple Magic Keyboards, this definitely concerns me.
The other thing that wasn’t clear to me is if the vulnerability exists if a Magic Keyboard isn’t in the mix. If I have never paired one to my laptop and instead I am use a different brand of Bluetooth keyboard is it still a problem?
In other words is this Magic Keyboard specific? I’m assuming the author had other Bluetooth keyboards. Of course even if it is that doesn’t mean there aren’t other vulnerabilities lurking in iOS/macOS in this area.
Still guessing here, but if I have a Magic Keyboard paired to my computer right now and I’m using it, is there any reason to let a second Magic Keyboard automatically pair itself?
If your Bluetooth device pretends to be the second Magic Keyboard and automatically pairs it could start injecting keystrokes. That seems like it would fit the description here.
Maybe (or maybe not) that involves pretending to be the first Magic Keyboard. Apple makes their stuff, they KNOW that no to have the same serial number (unlike some cheap stuff you can buy). But if they don’t protect against that…
Perhaps default pairing is left open to allow smoother pairing with iOS/iPadOS, as pairing otherwise would have required a cable with Lightning connector in both ends — which I don't think exists.