4 ms·

Oh snap, here we go again, convenience vs security, zero sum game.

amluto 3y ago
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.
- jeroenhd 3y ago
  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.
  - MBCook 3y ago
    > According to the write-up, the vulnerability itself was fixed years ago in BlueZ That’s the BlueZ vulnerability. Which is certainly different from the iOS/macOS vulnerability given Apple has their own BT stack. The decision made by the Linux kernel developers and distribution maintainers not to enable the fix by default is theirs. It doesn’t imply anything about Apple’s behavior. If Apple wasn’t aware of this, they couldn’t have made a security/convenience decision at all. Without knowing more it seems like jumping to conclusions. The Linux maintainers may have made a reasonable decision based on possible fallout from breaking lots of devices.
  - kelnos 3y ago
    To be fair, the Linux/BlueZ stack is only vulnerable while the adaptor is set to "discoverable" mode, which should be rare, and should only happen when the user sets it that way, for a limited time. 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.
segfaultbuserr 3y ago
Not just "convenience vs. security", also the plain old "backward compatibility vs. security". The BlueZ vulnerability was patched years ago but it was not enabled due to backward compatibility concerns: diff --git a/profiles/input/input.conf b/profiles/input/input.conf index 4c70bc561f..d8645f3dd6 100644 --- a/profiles/input/input.conf +++ b/profiles/input/input.conf @@ -17,7 +17,7 @@ # platforms may want to make sure that input connections only come from bonded # device connections. Several older mice have been known for not supporting # pairing/encryption. -# Defaults to false to maximize device compatibility. +# Defaults to true for security. #ClassicBondedOnly=true # LE upgrade security

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.

jeroenhd 3y ago
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.
- MBCook 3y ago
  > According to the write-up, the vulnerability itself was fixed years ago in BlueZ That’s the BlueZ vulnerability. Which is certainly different from the iOS/macOS vulnerability given Apple has their own BT stack. The decision made by the Linux kernel developers and distribution maintainers not to enable the fix by default is theirs. It doesn’t imply anything about Apple’s behavior. If Apple wasn’t aware of this, they couldn’t have made a security/convenience decision at all. Without knowing more it seems like jumping to conclusions. The Linux maintainers may have made a reasonable decision based on possible fallout from breaking lots of devices.
- kelnos 3y ago
  To be fair, the Linux/BlueZ stack is only vulnerable while the adaptor is set to "discoverable" mode, which should be rare, and should only happen when the user sets it that way, for a limited time. 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.

segfaultbuserr 3y ago

Not just "convenience vs. security", also the plain old "backward compatibility vs. security". The BlueZ vulnerability was patched years ago but it was not enabled due to backward compatibility concerns: diff --git a/profiles/input/input.conf b/profiles/input/input.conf index 4c70bc561f..d8645f3dd6 100644 --- a/profiles/input/input.conf +++ b/profiles/input/input.conf @@ -17,7 +17,7 @@ # platforms may want to make sure that input connections only come from bonded # device connections. Several older mice have been known for not supporting # pairing/encryption. -# Defaults to false to maximize device compatibility. +# Defaults to true for security. #ClassicBondedOnly=true # LE upgrade security