Live data from Hacker News

Thunderstrike – Apple EFI firmware vulnerability

trmm.net

41–50 of 72 posts

Re: Thunderstrike – Apple EFI firmware vulnerability

#41
The attack as described is plausible on non-Apple hardware, provided that the system doesn't have UEFI Secure Boot enabled. If it does then you'd need a separate attack to circumvent the requirement for signed drivers.

Also worth mentioning that this isn't specific to Thunderbolt - Expresscard also breaks out PCIe to an externally-accessible port.

Re: Thunderstrike – Apple EFI firmware vulnerability

#42
post #30

Extremely impressive this, the tenacity of the author is incredible. Basically the upshot of this article is (for me) that if you own some piece of hardware you can only really trust it if it has never been out of your sight after you bought it (and hopefully it wasn't compromised before you bought it). Shipping your laptop as checked in luggage, leave it on your desk overnight or go to lunch and when you see it the…

You'd probably be interested in Trammell's other projects (trmm.net has a list), including Magic Lantern, which arguably makes Canon cameras significantly more useful, and his older UAV work.

Definitely more than 'arguably' more useful. The intervalometer alone fills in for a $129 piece of hardware [0] and the HDR recording, although far from the standard of a Blackmagic camera, allows a $500 consumer SLR to produce HDR video where a $2000 camera would normally be required.

And those are just the features I could easily equate to money. There's also the zebra striping and so many other features I can't think of right now.

Magic Lantern is beautiful.

[0] http://www.bhphotovideo.com/c/product/164271-REG/Canon_2477A...

Re: Thunderstrike – Apple EFI firmware vulnerability

#43
post #42
post #30

Earlier quoted context omitted.

You'd probably be interested in Trammell's other projects (trmm.net has a list), including Magic Lantern, which arguably makes Canon cameras significantly more useful, and his older UAV work.

Definitely more than 'arguably' more useful. The intervalometer alone fills in for a $129 piece of hardware [0] and the HDR recording, although far from the standard of a Blackmagic camera, allows a $500 consumer SLR to produce HDR video where a $2000 camera would normally be required. And those are just the features I could easily equate to money. There's also the zebra striping and so many other features I can't th…

Interestingly the developers of Magic Lantern have explicitly stated that they will never develop it for the pro 1D and C ranges of cameras.

Apparently this is a result of some informal or undisclosed agreement with Canon, as the pro cameras are where Canon's recurring revenue lies.

Re: Thunderstrike – Apple EFI firmware vulnerability

#44
I can't wait for the same demo next year, but wireless. I wish I were joking:

  The WiGig Bus Extension (WBE), which can enable a wireless 
  version of the PCI Express (PCIe) slots used to connect 
  everything from video cards to hard drives. WBE is now a 
  published specification available to members of the 
  consortium.
WiGig Bus Extension (WBE) aka PCIe over Wi-Fi, coming to a laptop near you.

Re: Thunderstrike – Apple EFI firmware vulnerability

#45
post #37

There is an interesting opportunity here for a Thunderbolt "condom". You would permanently attach it to your Mac's TB port -- and plug everything through that. It would block Snare attacks by detecting/preventing PCIe reads in a certain address range. During boot time, it would read your BootROM and compare it against a known good and visually let you know if your ROM is compromised or not.

It is my understanding that verifying the BootROM is not possible once infected with sufficiently malicious code. I talked with Trammell about this briefly and my takeaway was that once you have code on the BootROM, you can control how code is read from the BootROM, making it possible to present the appearance of a non-compromised ROM image. To the best of my knowledge, the only solution is something sitting on top o…

I'll have to find the data sheet, but it should be very possible to pull a pin high or low to disable writing to the chip itself. I doubt they do any checks for being able to write to the chip in software, that would just wear out the flash unnecessarily.

Re: Thunderstrike – Apple EFI firmware vulnerability

#46
post #37

There is an interesting opportunity here for a Thunderbolt "condom". You would permanently attach it to your Mac's TB port -- and plug everything through that. It would block Snare attacks by detecting/preventing PCIe reads in a certain address range. During boot time, it would read your BootROM and compare it against a known good and visually let you know if your ROM is compromised or not.

It is my understanding that verifying the BootROM is not possible once infected with sufficiently malicious code. I talked with Trammell about this briefly and my takeaway was that once you have code on the BootROM, you can control how code is read from the BootROM, making it possible to present the appearance of a non-compromised ROM image. To the best of my knowledge, the only solution is something sitting on top o…

Thanks! I'll email him and ask for details.

However, I can't see how that would be possible. While it is possible for the BootROM to block reads to ROM once it is done executing or not execute external Optional ROMs but both of those would be detectable by the external accessory.

It is not possible for the ROM however to return a different set of data than what is in the ROM.

The only thing I can think of is if the PCIe bridge had aperture/remapping registers and it would alter those to point to RAM instead of ROM and copy a "good" ROM into that range but that would be detectable by writing to the address over PCIe and seeing if the region is writable.

Re: Thunderstrike – Apple EFI firmware vulnerability

#47
post #41

The attack as described is plausible on non-Apple hardware, provided that the system doesn't have UEFI Secure Boot enabled. If it does then you'd need a separate attack to circumvent the requirement for signed drivers. Also worth mentioning that this isn't specific to Thunderbolt - Expresscard also breaks out PCIe to an externally-accessible port.

I assume it was you that asked the question about Secure Boot at the end of this talk at 31C3?

Re: Thunderstrike – Apple EFI firmware vulnerability

#48

I can't wait for the same demo next year, but wireless. I wish I were joking: The WiGig Bus Extension (WBE), which can enable a wireless version of the PCI Express (PCIe) slots used to connect everything from video cards to hard drives. WBE is now a published specification available to members of the consortium. WiGig Bus Extension (WBE) aka PCIe over Wi-Fi, coming to a laptop near you.

There is already a wireless USB.

WBE would essentially replace the cable. It is invisible to upper stacks. There is encryption/scrambling. I'm sure there are vectors for snooping attacks but I don't see viable "imitation" attacks where you could issue commands on behalf of the other device.

Re: Thunderstrike – Apple EFI firmware vulnerability

#49
post #45

Earlier quoted context omitted.

It is my understanding that verifying the BootROM is not possible once infected with sufficiently malicious code. I talked with Trammell about this briefly and my takeaway was that once you have code on the BootROM, you can control how code is read from the BootROM, making it possible to present the appearance of a non-compromised ROM image. To the best of my knowledge, the only solution is something sitting on top o…

I'll have to find the data sheet, but it should be very possible to pull a pin high or low to disable writing to the chip itself. I doubt they do any checks for being able to write to the chip in software, that would just wear out the flash unnecessarily.

SPI flash has a write disable pin but that would also prevent Apple updates.

Re: Thunderstrike – Apple EFI firmware vulnerability

#50
post #37

There is an interesting opportunity here for a Thunderbolt "condom". You would permanently attach it to your Mac's TB port -- and plug everything through that. It would block Snare attacks by detecting/preventing PCIe reads in a certain address range. During boot time, it would read your BootROM and compare it against a known good and visually let you know if your ROM is compromised or not.

This is one of the original purposes for the Trusted Platform Module which Apple has never used and no longer even includes in their hardware.
Post reply on HN