21–30 of 265 posts
> 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.
Earlier quoted context omitted.
Alas, merely guessing, but it sounds like you can tell an apple device "I am the magic keyboard you know and trust" and it will believe you.
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?
> 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.
Earlier quoted context omitted.
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?
Perhaps there is a bug and the unique identifier isn't checked.
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…
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 :)
[flagged]
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.
Looks like this has just been fixed in iOS/macOS.
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
> 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.