3 ms·

The tragedy of FireWire: Collaborative tech torpedoed by corporations

westurner 6y ago
Due to DMA (Direct Memory Access) in most implementations, IEEE 1394 ("FireWire") can be used to directly read from and write to RAM. See: IEEE 1394 > Security issues https://en.wikipedia.org/wiki/IEEE_1394#Security_issues https://en.wikipedia.org/wiki/IEEE_1394#Security_issues FWIU, USB 3 is faster than FireWire; there are standard, interchangeable USB connectors and adapters; and USB implementations do not use DMA. https://en.wikipedia.org/wiki/USB_3.0 https://en.wikipedia.org/wiki/USB_3.0
- segfaultbuserr 6y ago
  > FWIU, USB 3 is faster than FireWire You've missed the point. The title of the article reads "The tragedy of FireWire" - how a good standard was victimized due to corporate politics. FireWire was 10 years ahead of USB. In 2002, FireWire 800 provided a data rate of 800 Mbps, full-duplex. On the other hand, USB 2 only had 480 Mbps, half-duplex. USB didn't catch up until 2010, after USB 3.0 was released. FireWire uses 30 V, 1.5 A power, and it supports power delivery up to 45 watts. USB didn't offer anything similar, not even the latest USB 3, until 2014 after Power Delivery and Type-C's standardization - and real applications only started to ramp up by ~2017. Both limitations of USB 2 were detrimental to some applications, e.g. using hard drives on a PC was painful due to speed and power constraints, had FireWire became more common, it would not be an issue. FireWire can also do everything Ethernet can do (in fact, 1394b's signaling is better than 100Base-TX Ethernet, and has lower radiation), networking is natively supported, you can network two computers together directly with a 1394 cable! On USB, it's only possible using an external controller. One application was NAS, a hard drive can be shared directly over 1394, and mounted as a local drive. Not possible with USB. Finally, 1394b does not have USB's 5-meter limitation due to protocol timing, and natively supports signaling over CAT-5 and fiber optics cable for a distance of ~50-100 meters - on USB, it requires a media converter running vendor-specific custom protocols and not interoperable. All of these features are standardized in 2004 in IEEE 1394b. Of course, limitations are not inherently USB 2's failures, they have different applications, FireWire was more expensive, and USB's goal was low-cost. But the tragedy was that bad business decision prevented FireWire to achieve its full potential, slowly fading out, and eventually became irrelevant after USB 3 despite its initial good engineering. FireWire was a tragedy. > Due to DMA (Direct Memory Access) in most implementations, IEEE 1394 ("FireWire") can be used to directly read from and write to RAM. This is why we need IOMMU. You should not blame IEEE 1394 for DMA attacks just because it supports DMA. I agree that the tragedy of FireWire probably prevented a common PC exploit vector as an lucky unintentional consequence, but it's just a symptom, not the actual issue - and the symptom has came back in another form. Most sufficiently fast hardware interfaces support DMA, and they're equally vulnerable - this includes PCI-E, ExpressCard (which exposes PCI-E), USB 4 (which exposes PCI-E port), Thunderbolt (which exposes PCI-E). Practical exploits are already widespread, not limited to arbitrary memory reads/writes, but also OptionROM arbitrary code execution if a Thunderbolt device is plugged in at boot time. And this is not only a problem for external ports like 1394, USB 4 or Thunderbolt. Threats also exist from internal devices, like a Ethernet or Wi-Fi controller on the motherboard. While you cannot initiate a DMA transaction via Ethernet (without RDMA) or Wi-Fi since they don't expose PCI-E, the fact that those are connected directly to PCI-E implies any vulnerability in the controller firmware potentially allows an attacker to launch a DMA attack. Exploits already exist for Wi-Fi controllers. This is the real problem. While the mechanism of IOMMU exists, CPU manufacturers and operating systems previously did little to systematically protect the system from DMA. In the past, Intel intentionally removed IOMMU functionality from low-end CPUs and motherboard chipsets in order to sell more Xeon CPUs to enterprise users. Also, while IOMMU is supported by operating systems, kernel code and drivers were not systematic audited for security - serious IOMMU bypass vulnerabilities have been previously discovered (and patched) in macOS and Linux's IOMMU implementations. With continued proliferation of USB 4 and Thunderbolt, the lack of IOMMU and buggy driver implementation will become a bigger problem. So far, QubesOS is most most protected operating system from DMA attacks. Untrusted hardware are assigned to a dedicated VM, and IOMMU is enforced by the hypervisor, not the individual device drivers in operating systems. Compromising a device driver in an untrusted domain does not directly expose the rest of QubesOS to attackers. > and USB implementations do not use DMA. USB 4 does now.
  - westurner 6y ago
    So your argument is that not security but cost is the reason that USB "won" the external device interface competition with FireWire? Good to know that USB4 implementations are making the same mistake as FireWire implementors did in choosing performance over security . Unfortunately it looks like there will be no alternative except for maybe to use a USB3 hub (or an OS with fuzzed IOMMU and also controller firmwares)? Could an NX bit for data coming from buses with and without DMA help at all? Hot gluing external ports now seems a bit more rational and justified for systems where physical access is less controlled.
    - segfaultbuserr 6y ago
      > So your argument is that not security, but cost is the reason that USB "won" the external device interface competition with FireWire? Sorry, but I heavily suspect that you didn't read the original article and I suggest you to do so. Security has nothing to do with 1394's market adoption, in the 2010s, some desktops still have 1394, and some laptops still have ExpressCard, and you don't see anyone complains about security, only some security researchers. The reason was partially cost, but also a bad business decision by Steve Jobs, which made Intel and Microsoft stopped their efforts for pushing 1394, largely damaged it before it even got a chance for wider adoption. > FireWire's principal creator, Apple, nearly killed it before it could appear in a single device. And eventually the Cupertino company effectively did kill FireWire, just as it seemed poised to dominate the industry. > Intel sent its CTO to talk to Jobs about the change, but the meeting went badly. Intel decided to withdraw its support for FireWire—to pull the plug on efforts to build FireWire into its chipsets—and instead throw its weight behind USB 2.0. > Sirkin believes that Microsoft could have reversed the new licensing policy by citing the prior signed agreement. "Microsoft must have thrown it away," he speculated, because it would have "stopped Apple in its tracks."* -- > Good to know that USB4 implementations are making the same mistake as FireWire implementors did in choosing performance over security. DMA is optional and can be disabled. Speaking of usability, DMA is limited to the Thunderbolt part (which is ultimately the PCI-E part) of USB 4 standard. You don't have to use USB 4's PCI-E. Unless the USB device really needs PCI-E, like RAID storage box or a GPU, disabling DMA is not a problem. Requiring explicit user consent for PCI-E is also a solution, operating systems already does it for Thunderbolt devices. Same treatment can be applied to USB 4. And again, calling out DMA support is only shooting the messenger while ignoring the underlying problem. DMA is essential for any high-performance system bus, and it can a problem regardless of who supported it, or whether it's connected to an external port. A Wi-Fi controller handles untrusted data, but despite being an internal device on the motherboard, it's still potentially an exploit vector for DMA attackers. > (or an OS with fuzzed IOMMU and also controller firmwares) Only IOMMU is needed (and possibly a good driver, but not strictly required, see QubesOS). If your IOMMU is good, you don't have to trust firmware or hardware, since arbitrary DMAs are blocked by IOMMU, just like how memory protection (MMU) works but for I/O. Memory spaces are isolated. The IOMMU vulnerabilities I previous mentioned are already patched, and a complete bypass of IOMMU is unlikely to occur in the future. Driver bugs are still an issue, more RAM regions can be exposed by drivers than what's really needed, and potentially you can pretend to be any hardware and feed bad data to trick the most vulnerable driver to expose more RAM regions, and I expect to see more bugs. Turn on IOMMU, and apply OS patches often, and you'll probably be fine.

Due to DMA (Direct Memory Access) in most implementations, IEEE 1394 ("FireWire") can be used to directly read from and write to RAM. See: IEEE 1394 > Security issues https://en.wikipedia.org/wiki/IEEE_1394#Security_issues https://en.wikipedia.org/wiki/IEEE_1394#Security_issues FWIU, USB 3 is faster than FireWire; there are standard, interchangeable USB connectors and adapters; and USB implementations do not use DMA. https://en.wikipedia.org/wiki/USB_3.0 https://en.wikipedia.org/wiki/USB_3.0

segfaultbuserr 6y ago
> FWIU, USB 3 is faster than FireWire You've missed the point. The title of the article reads "The tragedy of FireWire" - how a good standard was victimized due to corporate politics. FireWire was 10 years ahead of USB. In 2002, FireWire 800 provided a data rate of 800 Mbps, full-duplex. On the other hand, USB 2 only had 480 Mbps, half-duplex. USB didn't catch up until 2010, after USB 3.0 was released. FireWire uses 30 V, 1.5 A power, and it supports power delivery up to 45 watts. USB didn't offer anything similar, not even the latest USB 3, until 2014 after Power Delivery and Type-C's standardization - and real applications only started to ramp up by ~2017. Both limitations of USB 2 were detrimental to some applications, e.g. using hard drives on a PC was painful due to speed and power constraints, had FireWire became more common, it would not be an issue. FireWire can also do everything Ethernet can do (in fact, 1394b's signaling is better than 100Base-TX Ethernet, and has lower radiation), networking is natively supported, you can network two computers together directly with a 1394 cable! On USB, it's only possible using an external controller. One application was NAS, a hard drive can be shared directly over 1394, and mounted as a local drive. Not possible with USB. Finally, 1394b does not have USB's 5-meter limitation due to protocol timing, and natively supports signaling over CAT-5 and fiber optics cable for a distance of ~50-100 meters - on USB, it requires a media converter running vendor-specific custom protocols and not interoperable. All of these features are standardized in 2004 in IEEE 1394b. Of course, limitations are not inherently USB 2's failures, they have different applications, FireWire was more expensive, and USB's goal was low-cost. But the tragedy was that bad business decision prevented FireWire to achieve its full potential, slowly fading out, and eventually became irrelevant after USB 3 despite its initial good engineering. FireWire was a tragedy. > Due to DMA (Direct Memory Access) in most implementations, IEEE 1394 ("FireWire") can be used to directly read from and write to RAM. This is why we need IOMMU. You should not blame IEEE 1394 for DMA attacks just because it supports DMA. I agree that the tragedy of FireWire probably prevented a common PC exploit vector as an lucky unintentional consequence, but it's just a symptom, not the actual issue - and the symptom has came back in another form. Most sufficiently fast hardware interfaces support DMA, and they're equally vulnerable - this includes PCI-E, ExpressCard (which exposes PCI-E), USB 4 (which exposes PCI-E port), Thunderbolt (which exposes PCI-E). Practical exploits are already widespread, not limited to arbitrary memory reads/writes, but also OptionROM arbitrary code execution if a Thunderbolt device is plugged in at boot time. And this is not only a problem for external ports like 1394, USB 4 or Thunderbolt. Threats also exist from internal devices, like a Ethernet or Wi-Fi controller on the motherboard. While you cannot initiate a DMA transaction via Ethernet (without RDMA) or Wi-Fi since they don't expose PCI-E, the fact that those are connected directly to PCI-E implies any vulnerability in the controller firmware potentially allows an attacker to launch a DMA attack. Exploits already exist for Wi-Fi controllers. This is the real problem. While the mechanism of IOMMU exists, CPU manufacturers and operating systems previously did little to systematically protect the system from DMA. In the past, Intel intentionally removed IOMMU functionality from low-end CPUs and motherboard chipsets in order to sell more Xeon CPUs to enterprise users. Also, while IOMMU is supported by operating systems, kernel code and drivers were not systematic audited for security - serious IOMMU bypass vulnerabilities have been previously discovered (and patched) in macOS and Linux's IOMMU implementations. With continued proliferation of USB 4 and Thunderbolt, the lack of IOMMU and buggy driver implementation will become a bigger problem. So far, QubesOS is most most protected operating system from DMA attacks. Untrusted hardware are assigned to a dedicated VM, and IOMMU is enforced by the hypervisor, not the individual device drivers in operating systems. Compromising a device driver in an untrusted domain does not directly expose the rest of QubesOS to attackers. > and USB implementations do not use DMA. USB 4 does now.
- westurner 6y ago
  So your argument is that not security but cost is the reason that USB "won" the external device interface competition with FireWire? Good to know that USB4 implementations are making the same mistake as FireWire implementors did in choosing performance over security . Unfortunately it looks like there will be no alternative except for maybe to use a USB3 hub (or an OS with fuzzed IOMMU and also controller firmwares)? Could an NX bit for data coming from buses with and without DMA help at all? Hot gluing external ports now seems a bit more rational and justified for systems where physical access is less controlled.
  - segfaultbuserr 6y ago
    > So your argument is that not security, but cost is the reason that USB "won" the external device interface competition with FireWire? Sorry, but I heavily suspect that you didn't read the original article and I suggest you to do so. Security has nothing to do with 1394's market adoption, in the 2010s, some desktops still have 1394, and some laptops still have ExpressCard, and you don't see anyone complains about security, only some security researchers. The reason was partially cost, but also a bad business decision by Steve Jobs, which made Intel and Microsoft stopped their efforts for pushing 1394, largely damaged it before it even got a chance for wider adoption. > FireWire's principal creator, Apple, nearly killed it before it could appear in a single device. And eventually the Cupertino company effectively did kill FireWire, just as it seemed poised to dominate the industry. > Intel sent its CTO to talk to Jobs about the change, but the meeting went badly. Intel decided to withdraw its support for FireWire—to pull the plug on efforts to build FireWire into its chipsets—and instead throw its weight behind USB 2.0. > Sirkin believes that Microsoft could have reversed the new licensing policy by citing the prior signed agreement. "Microsoft must have thrown it away," he speculated, because it would have "stopped Apple in its tracks."* -- > Good to know that USB4 implementations are making the same mistake as FireWire implementors did in choosing performance over security. DMA is optional and can be disabled. Speaking of usability, DMA is limited to the Thunderbolt part (which is ultimately the PCI-E part) of USB 4 standard. You don't have to use USB 4's PCI-E. Unless the USB device really needs PCI-E, like RAID storage box or a GPU, disabling DMA is not a problem. Requiring explicit user consent for PCI-E is also a solution, operating systems already does it for Thunderbolt devices. Same treatment can be applied to USB 4. And again, calling out DMA support is only shooting the messenger while ignoring the underlying problem. DMA is essential for any high-performance system bus, and it can a problem regardless of who supported it, or whether it's connected to an external port. A Wi-Fi controller handles untrusted data, but despite being an internal device on the motherboard, it's still potentially an exploit vector for DMA attackers. > (or an OS with fuzzed IOMMU and also controller firmwares) Only IOMMU is needed (and possibly a good driver, but not strictly required, see QubesOS). If your IOMMU is good, you don't have to trust firmware or hardware, since arbitrary DMAs are blocked by IOMMU, just like how memory protection (MMU) works but for I/O. Memory spaces are isolated. The IOMMU vulnerabilities I previous mentioned are already patched, and a complete bypass of IOMMU is unlikely to occur in the future. Driver bugs are still an issue, more RAM regions can be exposed by drivers than what's really needed, and potentially you can pretend to be any hardware and feed bad data to trick the most vulnerable driver to expose more RAM regions, and I expect to see more bugs. Turn on IOMMU, and apply OS patches often, and you'll probably be fine.