91–100 of 265 posts
Earlier 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?
Why would you want to pair silently? Could someone provide more details on the intended purpose of the faulty mechanism?
Earlier quoted context omitted.
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?
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…
Because Bluetooth barely works normally for Windows
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?
On the devices affected? Who knows
Earlier quoted context omitted.
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?
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.
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…
Because Bluetooth barely works normally for Windows
And Bluetooth got quite a bit better on Windows 11 after the new audio profile thing is available
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” On the devices affected? Who knows