11–20 of 25 posts
Feel free to remove the FW driver from the OS.
I thought this was a hardware-based attack. Does it matter whether the OS supports firewire or not?
Lion even disables Firewire DMA when the screen is locked if you are running Filevault, or if you have an EFI password.
You mean with someone with physical access to my machine can trivially bypass software security measures? I am shocked, shocked , good sir!
This attack is hot precisely bc it blurs the local/remote line. Physical access is relative. 'Remote' vulns are still exploited with some level of physical access: i.e. via a network that lets you touch bits on the other side of the machine's ethernet jack / wireless card. The other extreme is standing over the ripped carcass of the machine case, triumphantly raising an unencrypted hard disk over your head, and blowi…
Added to the bucket list.
The issue here is that Apple, like most OS vendors, still don't seem to use the IOMMU facilities built into chipsets, especially for untrusted devices, like anything connected to a thunderbolt port. Considering that the Firewire attack has been known for several years, it's rather foolish that a company would implement a spec that can provide direct access to RAM without such basic precautions.
This is a deeper issue than just firewire. Yes, disabling firewire will stop this one vector of the attack, but there are plenty of other devices out there that can use DMA channels. I imagine someone halfway decent with vhdl and other languages can code an fpga that'll take the pci-e channel and enumerate as another device that the OS has DMA drivers for, like a SATA controller chipset or a sound card. From there, o…
I had thought that the OS X FW drivers didn't map any RAM until a driver requested some 1394 address space, but apparently that isn't the case... That would be the sane and easy way to fix this.
This is a deeper issue than just firewire. Yes, disabling firewire will stop this one vector of the attack, but there are plenty of other devices out there that can use DMA channels. I imagine someone halfway decent with vhdl and other languages can code an fpga that'll take the pci-e channel and enumerate as another device that the OS has DMA drivers for, like a SATA controller chipset or a sound card. From there, o…
SATA is not as straightforward, as far as I know there are no known attacks. It depends very much on the intface design, and you do not just get a pcie bus from sata. USB has some weak attacks apparently. Firewire and so on are mulimaster which is much more dangerous. No reason not to use iommu.
Earlier quoted context omitted.
This attack is hot precisely bc it blurs the local/remote line. Physical access is relative. 'Remote' vulns are still exploited with some level of physical access: i.e. via a network that lets you touch bits on the other side of the machine's ethernet jack / wireless card. The other extreme is standing over the ripped carcass of the machine case, triumphantly raising an unencrypted hard disk over your head, and blowi…
RAM which, for some goddamned reason on OS X, apparently contains an unencrypted copy of my login password? Really? Most software does that, most crypto software and encryption algorithms are vulnerable to RAM attacks. It's not as easy to protect against that as you think it is.
Feel free to remove the FW driver from the OS.
I thought this was a hardware-based attack. Does it matter whether the OS supports firewire or not?
"We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore."
If that's true then an option for those who need to use FW/TB devices is to remove the drivers from the system folder to prevent loading at startup and kextload/kextunload on demand.
The following named drivers are present in "/System/Library/Extensions/" :
IOFireWireAVC.kext IOFireWireFamily.kext //(The AppleFWOHCI.kext mentioned above is included here) IOFireWireIP.kext IOFireWireSBP2.kext IOFireWireSerialBusProtocolTransport.kext
IOThunderboltFamily.kext AppleThunderboltDPAdapters.kext AppleThunderboltEDMService.kext AppleThunderboltNHI.kext AppleThunderboltPCIAdapters.kext AppleThunderboltUTDM.kext