Bluetooth doesn’t need to exist.
And what do you propose as the alternative? How do you think people should connect their headphones, watches, fans, etc.
Bluetooth keystroke-injection in Android, Linux, macOS and iOS
151–160 of 265 posts
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#152Earlier quoted context omitted.
I made one to open locations in settings via open URL: prefs:root=Privacy&path=LOCATION
Wow, that's bonkers. I thought apple cared about privacy?
here's a list with all settings urls: https://github.com/FifiTheBulldog/ios-settings-urls/blob/mas...
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#153If 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
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.
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#154Earlier quoted context omitted.
Seems like the flag defaults to true since December 7 (Fedora 38) with bluez v5.70-4: $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1 * Thu Dec 07 2023 Peter Robinson - 5.70-4 - Add mitigation for CVE-2023-45866
This seems correct, however 'ClassicBondedOnly=true' is commented out in '/etc/bluetooth/input.conf' in Fedora 39 with bluez v5.70-4 anyways.
Presumably so you can't turn it off simply by uncommenting the line. The default is defined in some source file.
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#155> 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.
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.
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#156This is great news now that the industry phased out physical audio connection on phones in favor of wireless. Good job, guys.
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. [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
> 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.
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#157This is great news now that the industry phased out physical audio connection on phones in favor of wireless. Good job, guys.
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. [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
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?
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#158Earlier quoted context omitted.
> 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.
> surely I'd see the activity of the keystrokes being sent when using my device, no? That was my first thought as well. Then I remembered how much time my device spends in my pocket or on my nightstand
Right, but can it enter keystrokes when the device is locked? As in use the device "behind" the lock screen?
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#159Earlier quoted context omitted.
> 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?
It's apparently a feature of ancient Bluetooth
Re: Bluetooth keystroke-injection in Android, Linux, macOS and iOS
#160I 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.
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.