Live data from Hacker News

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

github.com

71–80 of 265 posts

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

#71

> 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.

[1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...

[2] https://ubuntu.com/security/notices/USN-4311-1

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

#72

> The Linux vulnerability was fixed in 2020 (CVE-2020-0556), but the fix was left disabled by default Experiment flags should have a timer to auto-flip them after a few months...

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.

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

#73
post #62

Earlier quoted context omitted.

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...

Am I missing something? Swipe from the top, tap to disable BT?

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.

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

#74
post #70
post #41

Earlier quoted context omitted.

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"?

So you are saying this is not true? You mean they got Google to react to a made up vulnerability? Did you even read the text?

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.

https://www.snopes.com/fact-check/iphone-namedrop-warning/

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

#75
post #25

This doesn't mention Windows at all. 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 environ…

I believe it's because they just didn't bother trying this on Windows (yet)

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

#76
post #45

>Once the attacker has paired with the target phone or computer 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.

> The vulnerabilities work by tricking the Bluetooth host state-machine into pairing with a fake keyboard without user-confirmation.

Is this possible to pair a keyboard device to Android without confirmation?

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

#77
post #20
post #12

Earlier quoted context omitted.

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.

Doesn't Android Auto carry audio over Bluetooth? That would be consistent with how unreliable the audio is.

If it's anything like CarPlay, it's absolutely NOT bluetooth.

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

#78
post #27

Earlier quoted context omitted.

I don't know. What's the wire for? Needing both the USB cable and Bluetooth has always struck me as pretty dumb.

The bluetooth connection is for phone calls. The rest of functionality works over the wire. As for the why does it need bluetooth at all, no idea.

Needs to be bluetooth so the handsfree controls on the steering wheel work without an outrageous degree of coupling.

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

#79
post #46

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…

> Android: disable Bluetooth when you're not using it (but you'll be vulnerable while you are).

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.

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

#80

Earlier quoted context omitted.

How in the world is this a CVSS 8.8 if this is the case? What a waste of everyone's time if this is true.

Ctrl+alt+t (insert malicious shell command)

Ok, but any reasonable threat model has assumed forever that physical access to the machine is essentially game over regardless.

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?

Post reply on HN