Inception – Break and Enter Using Direct Memory Access | Hacker News Reader

Inception – Break and Enter Using Direct Memory Access

breaknenter.org

72 pointsdeegles13 comments

This is super badass! I guess a lot of Proper Security People might say "whatever.. this requires physical access and once you have physical access you can compromise anything", but to truly say you can compromise any physically accessible system I'm sure you need large amounts of skill and resource. Beating FDE without doing something like [1] is really impressive to me. This is also a really interesting viewpoint on machine/protocol design.

[1] https://citp.princeton.edu/research/memory/media/

Edit: Also I wonder if there would be much worth in adding kernel interfaces to say "a new DMA-capable device was hotplugged - userspace should ask the user whether we should give them DMA access"? That would allow you to protect against these attacks without having to disable all your biz.

If we banned the hotplug of new devices when the system is in a locked state, would that be sufficient to mitigate these attacks via system buses with DMA access?

"No password? No hotplug for you." seems like a rule we ought to be enforcing.

  "Note: Mavericks since 10.8.2 on Ivy Bridge (>= 2012 Macs) 
  have enabled VT-D effectively blocking DMA requests and thwarting 
  almost all modules."

Looks like newer models have fixed it, but your suggestion would probably be nice for older systems.

Per the article: If you have a OF/EFI firmware password set on the target Mac OS X, FireWire DMA is off by default.

Not sure which year most accurately reflects the purpose of this submission vs. tagging older stuff (has anything noteworthy been added to this project recently?), but the title could be updated to include a [2011].

http://youtu.be/iTJApG0TMBQ?t=13m18s

https://hn.algolia.com/?query=inception+firewire&sort=byDate...

Very cool. First thought was: let's build a mobile lockpicker with a raspberry pi, but it doesn't have a firewire port :)

I've been saying for years that this was a major design flaw; it's great to have a practical exploit to point to.

I was thinking that the Physical Upper Bound Register (ohci_11.pdf, 5.1.5) should protect against that (at least where implemented, since it's "optional").

But it seems that even linux set this registers to allow pretty much everything (writes to OHCI1394_PhyUpperBound in src/drivers/firmware/*.c)

"Connect the attacker machine (host) and the victim (target) with a FireWire cable"

What keeps the target from starting an inception attack on the host?

Any of the things in the "Attack mitigation" section.

Not loading the firewire driver is not an option, as the attack needs the driver.

I guess loading the driver with DMA disabled would be a good option, as I don't think the attack needs DMA on the host side. Not sure, though, after skimming over the documentation.

Scary in 2011. A little less so in 2012. As of now, not very scary.

Great name! GPL too.

"The world’s forensics experts, governments and three-letter acronym agencies are using similar tools already, so why not?"

I'm not sure I understand that reasoning, but whatever.

Reply on news.ycombinator.com