41–50 of 265 posts
>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.
>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.
https://nvd.nist.gov/vuln/detail/CVE-2023-45866 https://lists.debian.org/debian-lts-announce/2023/12/msg0001... https://source.android.com/docs/security/bulletin/2023-12-01 https://support.apple.com/en-us/HT214036 https://support.apple.com/en-us/HT214035
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. Looks like this has just been fixed in iOS/macOS.
>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.
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.
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 dropp…
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 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.
Earlier quoted context omitted.
Doesn't Android Auto carry audio over Bluetooth? That would be consistent with how unreliable the audio is.
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.
Earlier quoted context omitted.
Maybe lazy convenience vs security? Apple has a rather nice, convenient way to pair a keyboard that ought to resist unauthenticated injection. The issues here appear to just be bugs.
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.
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.
> ChromeOS is the only Linux-based OS known to have enabled the fix 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.