I had to dig a little to figure this out, so, to keep yourself safe:
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 always hated that after an ios update bluetooth always came back as enabled... when I never actually used it... this puzzled me for a long time......
also, the emmentaler like wifi cannot be fully turned off from the control panel either
I was answering yours (perhaps reading it not the way you intended) and the grand parent's "HOWEVER 'ClassicBondedOnly=true' is commented out". No big deal. This style of option and comment and commenting out the option (default or not) is autopilot common - no special intent here.
Too bad iOS makes it very hard to disable bluetooth. Android was swipe+click, iOS it's swipe, two long presses, two clicks. Or you can type it, but that's obviously more clicks (though possibly faster).
I used to make the effort when I switched from Android, but I already gave up...
It makes sense for most people. When they want to turn those off they want to either disconnect from WiFi or disconnect from Bluetooth audio, and they don’t expect things like airdrop or their Apple Watch to stop working when they turn them off.
To be fair, the default behavior does exactly what I want: Disconnect me from a broken Wi-Fi network/Bluetooth headphone/speaker implementation that is hijacking my audio output, without breaking "Find My", Airdrop or Wi-Fi geolocation.
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.
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 trying this now and can’t figure this out. I’ve been trying for months now.
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)
The toggle in control centre does not disable Bluetooth. It disconnects Bluetooth until tomorrow. It even says that in control centre when you tap on the toggle.
Notice the difference in color when you do that. As the other comment pointed out, it only disconnects devices. Apple makes it hard for their users to disable bluetooth (or gps) so features like airtag work well.
You are sacrificing your battery life (and I guess privacy and security) for the ecosystem to work.
Google won't let you use GPS for maps without also turning on wifi for similar reasons I guess. It does make it more accurate but shouldn't be required.
Wasn’t there this thing that Google collected a list of SSIDs using their Google Maps cars, and that gave them “good enough” geolocation using passive WiFi scanning, which was much less battery intensive and faster than GPS?
Not sure. Doesn't the iphone lock you out for a day if you enter your pin wrong too often? If that pin-entering can be done via bluetooth.... More a prank than an attack, but still quite annoying.
I don't have a device lock because I keep the thing on my body and anyone violating that will also get the password anyhow and I don't want to have to authenticate a million times a day. That logic worked until now I guess :/
Any idea how to tell if grapheneOS fixed this in its sunfish (4a) branch? I'm stuck on android 13 with a 4a and I need Bluetooth to open my car door. If graphene fixed this, it would spur me to finally move to it. I just can't justify getting a new phone when this one works fine.
> 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.
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 :)
Maybe this particular hack isn’t vulnerable to Windows.
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.
I know it's a popular trope on HN to say nothing on Windows ever works but anecdotally I've been using Bluetooth on windows for over 10 years now from 7 to 11, and never had any issues whatsoever that were related to Windows itself.
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.
I’ve had a ton issues on Windows with Bluetooth and I know it’s not the hardware because on Linux it works fine.
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
I've experienced Bluetooth issues like that before on Windows. 100% of the time it's been solved by using a better Bluetooth adapter. I don't have any issues after using actually good Bluetooth adapters, such as modern Intel ones.
I could do that, but I’m using the built in Bluetooth on my desktop. Honestly, I’m just annoyed with Bluetooth and windows. Everything else not based on Windows work completely fine, from macOS to my multiple linux desktops
Are your Mac and Linux desktops using the same Bluetooth adapter as your Windows machines? If not, then maybe you do have an adapter issue and it's not the OS.
That's like arguing graphics suck in Linux compared to Windows because your 4090 in Windows works great but your CGA adapter you use on your one Linux desktop isn't that great. You're not doing a real comparison of like hardware, you're comparing different adapters across different OSes.
True, but I can’t feasibly rip out my wireless adaptor on my motherboard and connect it to my Mac.
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
I understand the desire to use Bluetooth, but there is a (relatively) cheap $20 adapter that uses a protocol and frequency more similar to WiFi I believe (like arctis gaming headsets if you’ve ever used those) which works much better. My experience with Bluetooth has always worked as far as connecting is concerned, but I had to use a TP Link Bluetooth adapter and disabled the motherboard Bluetooth to tell windows to use TP (it won’t assume for you). Even after being connected, I don’t think standard Bluetooth has the proper latency and bandwidth for the controller to work reliably in a crowded airspace (I live in an apartment). I will get small skips and latency spikes from time to time. The Xbox adaptor for PC makes it work basically just as effectively as connecting to an Xbox, with the only caveat being it will overheat pretty easily if you place it near an exhaust vent on the PC and are pumping hot air all around it. I put it on the front of my case and it stays cool enough there to work reliably.
The Xbox is a popular controller so its Bluetooth connection issues on windows should be well documented online by multiple users by now if it's a known issue. Or is it just you and a handful of unlucky users due to some buggy Bluetooth card-driver combo?
There are a lot of short straws you can pull in the Bluetooth stack lottery that don't necessarily stem from the OS.
A few of friends also have this experience with the controller. Nobody bothers to say anything though and they all told me that I’d just be better off plugging it in. Which is what they do and what I ended up doing
I've used an original Xbox One Bluetooth controller on Windows with about a dozen different Bluetooth adapters. I've never had problems. I also used a Bluetooth Xbox 360 controller before and once again didn't have issues. I also use a GuliKit Zen Pro controller without issues across close to half a dozen different Bluetooth adapters without issue. All in Windows.
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.
> I’ve had a ton issues on Windows with Bluetooth and I know it’s not the hardware because on Linux it works fine.
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.
Side note, have you tried a firmware update with the Xbox controller, inside the Xbox app for Windows? It helped me a lot, especially earlier generation / early production units.
(But yes, I always have issues with Bluetooth on Windows too)
I have, it’s on the latest firmware from the Xbox app. Still have these issues, the Xbox controller is just the biggest thing, my Sony headphones also have issues with Windows.
All of my coworkers have issues with anything regarding Bluetooth on Windows too
Could be one of two issues here. Either your old controller could have been faulty, or the other one, the new controller has a firmware update or HW revision that fixes the issue your old one had. Impossible to know without deeper dives in HW & FW revisions.
For me, it never went away. I had an Xbox One S controller before with the same issue. Bought the Xbox Series controller last year for Elden Ring, same issue on Windows. Gave up, and just got a longer USB C cable.
I think you mixed up Windows and Linux. Or maybe both have their share of problems. Or maybe it is, as some people here say, impossible to implement Bluetooth properly.
This vulnerability is about injecting keystrokes into connected wireless keyboards and mice.[1] With the phone industry adoption of USB-C, they've made wired easier than ever before.
What does this have to do with the fact that now people have to switch on bluetooth for audio, instead of having a cable connection? And an attack requiring a physical cable connection is a little bit more visible, and less viable if I have my phone in my hand, than a wireless attack via bluetooth, don't you think?
You don’t “have to” switch to only wireless. There are plenty of inexpensive usb-c DACs and even the overpriced Apple usb-c to 3.5mm adapter is a whopping $9.
> This is great news now that the industry phased out physical **audio** connection on phones in favor of wireless.
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.
This comment is generating far more snark than the parent to be frank.
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
The vulnerabilities work by tricking the Bluetooth host state-machine into pairing with a fake keyboard without user-confirmation. The underlying unauthenticated pairing mechanism is defined in the Bluetooth specification, and implementation-specific bugs expose it to the attacker.
Why would you want to pair silently? Could someone provide more details on the intended purpose of the faulty mechanism?
In the bluetooth spec? For various non-computer things, like being able to pair your first controller to your playstation, without having to plug in an usb mouse to click ”allow pairing”
There are set-top boxes/TVs running android/linux that might have the same use-case for remotes/controllers and macOS/iOS share a lot of code with tvOS which has the same use-case. Macs ship with wireless keyboards that automatically pairs, apple even highlight this on their product page: "It pairs automatically with your Mac, so you can get to work right away." https://www.apple.com/shop/product/MMMR3LL/A/magic-keyboard-...
It's just an older design from a more innocent time, newer specifications don't allow this, but to maximise compatibility Bluetooth stacks left the new behaviour off.
> I was intimidated by Bluetooth at the time, and just sort of assumed it was secure. I didn't try to hack any Bluetooth devices, and I recommended Bluetooth as a secure alternative to the plethora of custom protocols. It never occurred to me that Bluetooth would have trivial keystroke-injection vulnerabilities like the MouseJack protocols, so I never looked.
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
I doubt this is practical for use against phones or computers, but if you're responsible for keeping people from messing with kiosks your life just got more interesting.
I had accidentally exposed a Linux machine with a passwordless vnc to the Internet a good decade ago. A few minutes in I got someone connecting trying to run stuff via automated keystrokes that were obviously targeting Windows. You only need to successfully get a backdoor in and work from there.
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".
By the way, USB is similar. If you connect a keyboard to "charging only" port, it works. Tried myself on Android. Was told off here it's supposedly not practically exploitable.
Do you only use your port on Android for charging? It's also super useful for HDMI. And, yeah, peripherals.
I don't consider that a vulnerability though. It's just useful. The problem here is someone can do it without you noticing them and while you're using it for sensitive things.
Perhaps you missed that "charging only" is a setting for when you really only want to allow charging when the charger is sus? At any other time, sure, get wild.
You said a "charging only" port, thanks for the clarification. I interpreted that as the physical port, not an android setting to filter communications on the port. I don't think I'd ever trust a random cable even with an OS config setting.
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.
> The Linux vulnerability was fixed in 2020 (CVE-2020-0556), but the fix was left disabled by default. ChromeOS is the only Linux-based OS known to have enabled the fix, even though it was announced by Ubuntu, Debian, Fedora, Gentoo, Arch and Alpine.
Took all of 30 seconds to verify it's in NixOS[1]. Another 30 seconds to see it was patched a week ago, at "Dec 8, 2023, 8:23 AM GMT+13", a day after the article was published (Dec 7, 2023, 10:18 AM GMT+13). :shrug:
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.
If you can silently pair to a phone, you can make the phone dial whatever number you want. Recently found this out when connecting the serial terminal to an earbud for repair (it wouldn't auto-connect to the other earbud).
How would you reliably unlock the phone and get to the dialer app? Given how varied home screen layouts are, even an unlocked phone might be hard to attack this way
That's not what I mean. You can instruct the phone - over bluetooth, within the bluetooth functionality - to dial a number. No lock screen or dial app to access.
You can always reset by tapping the home button or swiping the most recent app away or so, so you can try various UI layouts until one works. Most Androids have a settings button in the notification area and then you can find the installed apps, search for the dialer, etc. Don't need to assume a certain homescreen location.
I'm going to guess that Apple made some decisions here to trade off security for usability so the Magic Keyboard can "work like magic" regardless of what stage of the boot cycle, recovery mode, etc the computer is in, and this vulnerability takes advantage of that.
I have no idea if usability with bluetooth keyboards is affected in different boot states. It certainly isn't affected during normal use, but I don't know about the various recovery modes.
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.
Honestly, I'm not surprised. Bluetooth is an unsecured microcontroller that does not run an open source firmware (and yes, I'm aware, the CVE is partially enabled by the software stack as well). By definition, that is a security nightmare.
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).
As is the baseband, or the Wi-Fi chip, or most of the other components in a modern phone.
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.
Wireless keyboard generally seem like a totally terrible idea, just waiting for hacks. The author mentions not going after wireless gaming keyboards because they were the “wrong kind of mess,” I assume, security through abstrusity :)
I never really understood the benefits of a wireless keyboard. Do people usually carry their keyboard from their desk with them when they take their laptop somewhere else?
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.
> Do people usually carry their keyboard from their desk with them when they take their laptop somewhere else?
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 laptop by default is not suitable for working any substantial length of time due to the fixed coupling between its screen and keyboard. Separating them—so that you can relax while keeping your screen roughly at your eye level and at comfortable distance, and your elbows bent at comfortable 90 degrees (or more)—gets you 80% there in terms of ergonomics.
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.
I would not argue that wired is more reliable in terms of connection. It’s just that if you’re working at a laptop then connection reliability competes with wear and tear, ergonomics, and outlier scenarios like “trip on a cable and brick your work machine” (e.g., by spilling coffee or dropping it). In case of a desktop, connection reliability only competes with ergonomics, and to a much lesser extent—I can see myself using a wired keyboard at a desktop, perhaps even a split one (and that’s an additional wire).
Anecdotally, I don’t tend to run into connection issues with wireless keyboards—I do with wireless mice, however.
Hm, yeah, laptops are a bit difficult ergonomically. For me, just the hassle of "this is misbehaving again, is it the battery or interference?" is enough to prefer wired everything, but I get your point about wear and tear.
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’ve had many similar issues with ports, to be honest. Just recently had to get the I/O board swapped on an M1 MBP—one day it decided that one of the USB ports wouldn’t connect 80% of the time. It was relatively inexpensive to do officially even without the warranty (around US$60 all in all), and took just a couple of days, to be fair.
Huh, maybe I'm an outlier. Maybe it's the way you remove your connectors? Some people tend to wiggle them side-to-side, 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. That leads to the removing force vector pointing strictly straight out of the connector, and I've never had a problem with any port.
Past me was definitely careless. Current me—doubtful, or at least I’d like to think I’d have learned to be nicer to ports…
> 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).
Either you mean a desktop machine, or I envy you. Every one of my laptops had developed issues with physical I/O (be it ports, keyboard, trackpad). The one I especially hate is flaky USB ports that make external HDD spontaneously disconnect while being heavily used, like copying many files over (and it’s not a power issue as it happened both while laptop is powered and with HDDs that have their own dedicated power).
Ah, I use a Framework, so if (when?) a physical port goes bad, I can just replace it for $10 or whatnot. I've never had issues like you mention, though.
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.
My previous laptop had indeed its SD slot borked at some point (part of why I don’t care that my new laptop lacks it—I would just not expect it to work reliably, so why have another dust collection point). My first laptop’s keyboard had very occasionally working keys in the middle (I blame my pianist fingers bashing them too hard)—I count that as physical I/O, though not a port issue.
Is it easy to source replacement I/O boards for Framework?
You may want to get one with replaceable switches, I built one and had one or two switches go bad after a few years, I popped them off, plugged new ones in, and that was it. Lifesaver.
Much respect for people building keyboards (a colleague’s done it as well). Since I’d love to have a compact split one (whether wired or not), and apparently it’s quite hard to find them pre-built and in stock, it looks like I’d have to get into building them as well. It’d be a while though, gotta move to a bigger place to have the space to build anything at all.
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?
A friend builds wireless keyboards, so I guess they must be fine now with ZMK, but the issue I had with mine and QMK was that I never knew if the battery was dying or if the keyboard was just being flaky. I switched to wired and never looked back, but, to be fair, it is for a desktop computer.
The only case I like for it is, I’ve got a windows computer that I plug into the TV for gaming (glorified console really). It is nice to not have wires across the room.
Not everyone cares about the aesthetics of their tools or shares your sense of aesthetics (minimalism). Furthermore: OP and things like mousejack are exactly tbe reason why some people will not use a wireless input device.
Keyboards are used to enter secrets so they rank pretty high in my threat model.
For some reason Bluetooth has to be enabled for Android Auto to work, even though it's wired, so I leave it enabled. But there should be a way to just disable keyboards categorically, for phones.
Hey don’t knock it until you’ve tried Apple’s equivalent (wireless CarPlay) which has a 3 second buffer since they decided to use Wi-Fi for audio. Imagine if every time you play or pause or change tracks you have to count to three in your head before it responds.
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.
Wait, what? Wifi? Does that mean that a car that has CarPlay must also have Wifi that can act as an access point, and do some sort of automatic connection negotiation when the phone is plugged in and CarPlay is activated? That seems... terrible.
Wireless CarPlay didn't show up until several years after the original USB-based CarPlay, which is still around and there may still be new vehicles on the market which only support the USB-based CarPlay. Wireless CarPlay starts with a Bluetooth connection which is then used to negotiate the higher-bandwidth WiFi link. Neither CarPlay nor Android Auto can operate on Bluetooth alone, because the video data that needs to be streamed far exceeds what Bluetooth can handle.
Can someone walk me through the process of exploiting Android or iOS with this? I never attached a keyboard to my phones. How do I get to the app store and download an app using just the keyboard? On iOS it requires the fingerprint if I remember correctly, at least on mine. But it's for work and I do mostly very basic stuff with it, so I could be wrong.
On Android for free apps I believe the default is no password confirmation
Assuming recent versions, you could press home + type "Play Store" to search and open the app, search for something and install without a password, assuming an unatended device, in my phone at least you can click to wake up the screen
You can, I just tested, 2 tabs + Enter get you writing on the Search Box
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
This is a pretty tremendous hack. Almost all computers are vulnerable and if you can get close enough to them you can quickly send keyboard presses to open a terminal window and install software (hopefully the password request saves you at this point).
Qubes uses hardware virtualization to isolate different hardware, including audio stack, USB devices, into dedicated virtual machines. You do not normally run anything there except the drivers.
I use a UBPorts Pinephone as my daily driver. Sometimes I wonder about the security implications of that decision. I imagine there are WAY more vulnerabilities for a phone like mine, compared to iOS/Android. It's buggy enough from a user perspective, let alone a security one. Does anyone have any knowledge or thoughts in this regard?
> iOS and macOS are vulnerable when Bluetooth is enabled and a Magic Keyboard has been paired with the phone or computer
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?
> I'm really not sure what sort of wireless keyboard to recommend at this point. If you are reading this and you make a secure wireless keyboard, please send me one so I can hack it for you.
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?
It's a reference back to where they stated that they used to recommend Bluetooth wireless keyboards. These attacks only involve keyboards to the extent that Apple devices have to be paired with a keyboard for them to work.
“Paired” in the sense of “the device knows this particular keyboard because it has been paired with it at some point in the past”, or in the sense of “currently connected”?
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).
A wireless keyboard that didn't use Bluetooth wouldn't be vulnerable to this.
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.
If it’s “paired” in the first sense, then merely using a non-Bluetooth keyboard is not sufficient, you also have to make sure to unpair any previously paired Bluetooth devices. It would therefore seem important to find out what precisely is the case.
Not just "convenience vs. security", also the plain old "backward compatibility vs. security". The BlueZ vulnerability was patched years ago but it was not enabled due to backward compatibility concerns:
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 security
According to the write-up, the vulnerability itself was fixed years ago in BlueZ, but left disabled by default for compatibility. I'm not sure about the macOS vulnerability, but at least on the Linux side, usability beat security.
> According to the write-up, the vulnerability itself was fixed years ago in BlueZ
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.
To be fair, the Linux/BlueZ stack is only vulnerable while the adaptor is set to "discoverable" mode, which should be rare, and should only happen when the user sets it that way, for a limited time.
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.
This is a bad idea, and maybe if you think about it a few minutes you could come up with the reasons why, yourself.
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.
Release schedules are normal. That's how every deprecation scheme works: announce the change and follow through on date xyz. But I'm sure we'll see the light if only we think about it for a few minutes.
Yes, i am reading the title which says 'Bluetooth keystroke-injection' which is concerning on one level, but in fact the article talks about authenticating a device without user interaction which seems way more serious to me.
however, it also mentions
> stay tuned for Part 2: More Vulnerabilities
That is only part of the CVSS scoring system. Not only do you need near-physical access (i.e. not open to the internet, already drops the rating significantly), it requires the victim to interact with a suspicious prompt, which basically drops it to the level of a phishing email (i.e. not CVSS 8.8).
This is an automatic bluetooth pairing attack. With the right equipment (which can be as simple as a Pringles can and an antenna aimed through a window) you can execute this attack from a hundred meters away. That's not physical access.
People are silly about security. Has your social media not been flooded with oldsters circulating that copypasta about how iOS contact sharing is going to let thieves "STEAL YOUR INFO!!1?!111"?
They’re not talking about this. They’re talking about the NameDrop feature added in iOS 17. The one with multiple confirmation steps, while the facebook memes talk like hackers can steal your info from long range with no intervention.
I would be a lot more supportive of ChromeOS if it wasn't controlled by Google. It seems like it's mainly a vehicle to get students and others hooked on Google services and further normalize Google's brand of ad tracking and surveillance capitalism.
It seems like it had no competitors though, why wouldn’t it have become a standard? Without it, we would only have proprietary incompatible wireless everything.
I’m happy enough with most of my Bluetooth things.
Bluetooth is the gift that keeps on giving. Not sure why my Ubuntu insists on enabling it on every boot, at least on my hardware.
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.
That’s considerably worse than most people experience - keyboard latency is normally under 15ms - and I think that’s part of the problem there: if you live somewhere with a lot of congestion from other devices, poorly shielded microwave ovens, etc. you have a legitimately terrible experience but it’s not common enough for it to actually get fixed since it doesn’t impact sales.
Latency is something I notice, but having used Bluetooth since it first came out, 500+ms is either a very noisy radio environment or defective hardware. It’s freakishly outside of normal for the technology - if you were seeing 5ms, maybe 10ms, that’d be within expectations but not even 50ms.
Modern devices should be in the 10-15ms range. If yours are not, return them as defective.
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.
I read the original article to find the narrow range of conditions. It states "iOS and macOS are vulnerable when Bluetooth is enabled and a Magic Keyboard has been paired with the phone or computer" so does this mean if a computer has ever paired with a Magic Keyboard, it would allow itself to be paired with additional keyboards that the user did not want to pair?
As someone who has bought multiple Magic Keyboards, this definitely concerns me.
I’m sort of assuming the Magic Keyboard has to be present, but we don’t know that based on the write up. It’s a great question though. All desktop Macs come pre-paired with a Magic Keyboard even if you never use it. so if the keyboard doesn’t have to be actively connected at the time that would make them all vulnerable unless someone had unpaired them.
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.
Wouldn't that require knowing/guessing/brute-forcing a unique device identifier that's probably not available to be sniffed if the genuine keyboard in question isn't in use?
That was sort of the impression I got. It’s not that Apple is doing something unfixable, it’s that they have a bug that enables something that shouldn’t happen.
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…
Apple's "Magic Keyboard" is supposed to exchange Bluetooth keys with a MacOS host over its USB/Lightning cable the first time it gets plugged in.
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.
I was pretty surprised to see that Linux/BlueZ is only vulnerable under a very specific, rare situation. And fixing it for that situation doesn't even require a patch, just a small change to a configuration file. BlueZ (and its related GUI tools) otherwise is a usability nightmare. At least it's decently secure?
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.