1. 11 Mar, 2020 3 commits
  2. 08 Mar, 2020 7 commits
  3. 07 Mar, 2020 1 commit
  4. 04 Mar, 2020 4 commits
  5. 01 Mar, 2020 1 commit
  6. 28 Feb, 2020 13 commits
  7. 19 Feb, 2020 2 commits
  8. 18 Feb, 2020 5 commits
  9. 16 Feb, 2020 1 commit
  10. 14 Feb, 2020 2 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Add BT_PHY socket option · eab2404b
      Luiz Augusto von Dentz authored
      This adds BT_PHY socket option (read-only) which can be used to read
      the PHYs in use by the underline connection.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      eab2404b
    • Howard Chung's avatar
      Bluetooth: secure bluetooth stack from bluedump attack · cee5f20f
      Howard Chung authored
      Attack scenario:
      1. A Chromebook (let's call this device A) is paired to a legitimate
         Bluetooth classic device (e.g. a speaker) (let's call this device
         B).
      2. A malicious device (let's call this device C) pretends to be the
         Bluetooth speaker by using the same BT address.
      3. If device A is not currently connected to device B, device A will
         be ready to accept connection from device B in the background
         (technically, doing Page Scan).
      4. Therefore, device C can initiate connection to device A
         (because device A is doing Page Scan) and device A will accept the
         connection because device A trusts device C's address which is the
         same as device B's address.
      5. Device C won't be able to communicate at any high level Bluetooth
         profile with device A because device A enforces that device C is
         encrypted with their common Link Key, which device C doesn't have.
         But device C can initiate pairing with device A with just-works
         model without requiring user interaction (there is only pairing
         notification). After pairing, device A now trusts device C with a
         new different link key, common between device A and C.
      6. From now on, device A trusts device C, so device C can at anytime
         connect to device A to do any kind of high-level hijacking, e.g.
         speaker hijack or mouse/keyboard hijack.
      
      Since we don't know whether the repairing is legitimate or not,
      leave the decision to user space if all the conditions below are met.
      - the pairing is initialized by peer
      - the authorization method is just-work
      - host already had the link key to the peer
      Signed-off-by: default avatarHoward Chung <howardchung@google.com>
      Acked-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      cee5f20f
  11. 13 Feb, 2020 1 commit