8 ms·

> That doesn’t make sense. Attackers will just pretend to be one of the permitted devices. I don't have much knowledge on how the block actually works, but I w

> That doesn’t make sense. Attackers will just pretend to be one of the permitted devices. I don't have much knowledge on how the block actually works, but I would assume it's not trivial to "just pretend to be one of the permitted devices." > There are also hardware mitigations to make DMA safe(r) now. From what I can tell, IOMMU is not supported on any of the CPUs used by Thunderbolt-capable MacBooks.

wyager 9y ago
> but I would assume it's not trivial to "just pretend to be one of the permitted devices." Your assumption is incorrect. Even for devices that are designed with the express purpose of being hard to emulate (auth tokens, DRM chips, iPhone cables), it’s at most a simple matter of a grad student or Shenzhen resident with access to a fume hood and an electron microscope finding some burned-in private keys. For devices that aren’t designed to resist emulation, which thunderbolt devices generally aren’t, it’s trivial. This is essentially one of the core messages you should take away from the field of hardware security. > IOMMU is not supported on any of the CPUs used by Thunderbolt-capable MacBooks. They all do. Intel calls it VT-d.
- darpa_escapee 9y ago
  I have a MacBook with processor that supports VT-d according to ARC. I cannot use VT-d features.
- txcwpalpha 9y ago
  >Your assumption is incorrect. Even for devices that are designed with the express purpose of being hard to emulate (auth tokens, DRM chips, iPhone cables), it’s at most a simple matter of a grad student or Shenzhen resident with access to a fume hood and an electron microscope finding some burned-in private keys. For devices that aren’t designed to resist emulation, which thunderbolt devices generally aren’t, it’s trivial. This is essentially one of the core messages you should take away from the field of hardware security. Every source that I can find regarding the 2016 DMA vulnerabilities disagrees with you. Most of them actually specifically require that Thunderbolt security features be turned off because otherwise signed drivers are required to be installed before the peripheral will even connect. >They all do. Intel calls it VT-d. Got a source for VT-d being supported on MacBooks? I've been looking pretty hard to find a definitive answer, but all I can find are random unverified forum posts, stackoverflow questions, blackhat presentations, etc, and all of them say that VT-d and IOMMU are not supported/enabled on recent MacBooks and MB Pros. edit: I finally came across the below link from Apple which does seem to imply that IOMMU VT-d is enabled on Macs that are 2012 and newer. On anything before that, though, and DMA attacks could own you. So uh.. don't run macbooks that are 6 years old, I guess. https://developer.apple.com/library/content/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/DebuggingThunderboltDrivers/DebuggingThunderboltDrivers.html https://developer.apple.com/library/content/documentation/Ha...
  - pktgen 9y ago
    According to Wikipedia [1], the current 15" MBP base config has an i7-7700HQ. According to Intel [2], that CPU supports VT-d. Every mobile chipset in the 100 series (for Skylake) supports VT-d [3]. The 200 series is supposed to be the one for Kaby Lake, but there are no mobile chipsets listed in that series [4]. Also, there are several MBP models with IOMMU support on the Qubes HCL [5]. [1] https://en.wikipedia.org/wiki/MacBook_Pro#Technical_specifications_4 https://en.wikipedia.org/wiki/MacBook_Pro#Technical_specific... [2] https://ark.intel.com/products/97185/Intel-Core-i7-7700HQ-Processor-6M-Cache-up-to-3_80-GHz https://ark.intel.com/products/97185/Intel-Core-i7-7700HQ-Pr... [3] https://ark.intel.com/products/series/98456/Intel-100-Series-Chipsets#@mobile https://ark.intel.com/products/series/98456/Intel-100-Series... [4] https://ark.intel.com/products/series/98457/Intel-200-Series-Chipsets https://ark.intel.com/products/series/98457/Intel-200-Series... [5] https://www.qubes-os.org/hcl/ https://www.qubes-os.org/hcl/
  - wyager 9y ago
    > Most of them actually specifically require that Thunderbolt security features be turned off because otherwise signed drivers are required to be installed before the peripheral will even connect. You’re on the wrong page here. I’m not really sure what your thought process is. The (easy) attack is to simply trick the host machine and driver into thinking you’re an approved DMA-capable device. It has nothing to do with host-side checks on the drivers. > Got a source for VT-d being supported on MacBooks? Intel’s website and my memory. > So uh.. don't run macbooks that are 6 years old, I guess. This thread is specifically talking about thunderbolt 3, so this precludes any such machines.
95014_refugee 9y ago
> I don't have much knowledge on how the block actually works, but I would assume it's not trivial to "just pretend to be one of the permitted devices." Why would you assume such a thing? There's no historical precedent for peripheral authentication in the PCI space, nor indeed for any of the common peripheral interfaces. The closest you get is "you get the driver that claims to best service the thing you claim to be", which makes pretending to be something you're not less useful from a functional perspective, but does nothing for system security.
- txcwpalpha 9y ago
  I'm not sure why you would think of any of that. Peripherals for a long time have had authentication in the form of requiring signed drivers to work properly. Reviewing the information from the published 2016 MacBook DMA vulnerabilities specifically addresses this.
  - cstrahan 9y ago
    You’ve just changed your argument from “it’s probably difficult to spoof a vendor/device ID” to “drivers have historically required signatures”.

wyager 9y ago

> but I would assume it's not trivial to "just pretend to be one of the permitted devices." Your assumption is incorrect. Even for devices that are designed with the express purpose of being hard to emulate (auth tokens, DRM chips, iPhone cables), it’s at most a simple matter of a grad student or Shenzhen resident with access to a fume hood and an electron microscope finding some burned-in private keys. For devices that aren’t designed to resist emulation, which thunderbolt devices generally aren’t, it’s trivial. This is essentially one of the core messages you should take away from the field of hardware security. > IOMMU is not supported on any of the CPUs used by Thunderbolt-capable MacBooks. They all do. Intel calls it VT-d.

darpa_escapee 9y ago
I have a MacBook with processor that supports VT-d according to ARC. I cannot use VT-d features.
txcwpalpha 9y ago
>Your assumption is incorrect. Even for devices that are designed with the express purpose of being hard to emulate (auth tokens, DRM chips, iPhone cables), it’s at most a simple matter of a grad student or Shenzhen resident with access to a fume hood and an electron microscope finding some burned-in private keys. For devices that aren’t designed to resist emulation, which thunderbolt devices generally aren’t, it’s trivial. This is essentially one of the core messages you should take away from the field of hardware security. Every source that I can find regarding the 2016 DMA vulnerabilities disagrees with you. Most of them actually specifically require that Thunderbolt security features be turned off because otherwise signed drivers are required to be installed before the peripheral will even connect. >They all do. Intel calls it VT-d. Got a source for VT-d being supported on MacBooks? I've been looking pretty hard to find a definitive answer, but all I can find are random unverified forum posts, stackoverflow questions, blackhat presentations, etc, and all of them say that VT-d and IOMMU are not supported/enabled on recent MacBooks and MB Pros. edit: I finally came across the below link from Apple which does seem to imply that IOMMU VT-d is enabled on Macs that are 2012 and newer. On anything before that, though, and DMA attacks could own you. So uh.. don't run macbooks that are 6 years old, I guess. https://developer.apple.com/library/content/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/DebuggingThunderboltDrivers/DebuggingThunderboltDrivers.html https://developer.apple.com/library/content/documentation/Ha...
- pktgen 9y ago
  According to Wikipedia [1], the current 15" MBP base config has an i7-7700HQ. According to Intel [2], that CPU supports VT-d. Every mobile chipset in the 100 series (for Skylake) supports VT-d [3]. The 200 series is supposed to be the one for Kaby Lake, but there are no mobile chipsets listed in that series [4]. Also, there are several MBP models with IOMMU support on the Qubes HCL [5]. [1] https://en.wikipedia.org/wiki/MacBook_Pro#Technical_specifications_4 https://en.wikipedia.org/wiki/MacBook_Pro#Technical_specific... [2] https://ark.intel.com/products/97185/Intel-Core-i7-7700HQ-Processor-6M-Cache-up-to-3_80-GHz https://ark.intel.com/products/97185/Intel-Core-i7-7700HQ-Pr... [3] https://ark.intel.com/products/series/98456/Intel-100-Series-Chipsets#@mobile https://ark.intel.com/products/series/98456/Intel-100-Series... [4] https://ark.intel.com/products/series/98457/Intel-200-Series-Chipsets https://ark.intel.com/products/series/98457/Intel-200-Series... [5] https://www.qubes-os.org/hcl/ https://www.qubes-os.org/hcl/
- wyager 9y ago
  > Most of them actually specifically require that Thunderbolt security features be turned off because otherwise signed drivers are required to be installed before the peripheral will even connect. You’re on the wrong page here. I’m not really sure what your thought process is. The (easy) attack is to simply trick the host machine and driver into thinking you’re an approved DMA-capable device. It has nothing to do with host-side checks on the drivers. > Got a source for VT-d being supported on MacBooks? Intel’s website and my memory. > So uh.. don't run macbooks that are 6 years old, I guess. This thread is specifically talking about thunderbolt 3, so this precludes any such machines.

95014_refugee 9y ago

> I don't have much knowledge on how the block actually works, but I would assume it's not trivial to "just pretend to be one of the permitted devices." Why would you assume such a thing? There's no historical precedent for peripheral authentication in the PCI space, nor indeed for any of the common peripheral interfaces. The closest you get is "you get the driver that claims to best service the thing you claim to be", which makes pretending to be something you're not less useful from a functional perspective, but does nothing for system security.

txcwpalpha 9y ago
I'm not sure why you would think of any of that. Peripherals for a long time have had authentication in the form of requiring signed drivers to work properly. Reviewing the information from the published 2016 MacBook DMA vulnerabilities specifically addresses this.
- cstrahan 9y ago
  You’ve just changed your argument from “it’s probably difficult to spoof a vendor/device ID” to “drivers have historically required signatures”.