4 ms·

Inception – Break and Enter Using Direct Memory Access

72 points by deegles 12y ago

NKCSS 12y ago
Very cool. First thought was: let's build a mobile lockpicker with a raspberry pi, but it doesn't have a firewire port :)
aceperry 12y ago
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.
jannic 12y ago
"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?
- lmm 12y ago
  Any of the things in the "Attack mitigation" section.
  - jannic 12y ago
    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.
lmm 12y ago
I've been saying for years that this was a major design flaw; it's great to have a practical exploit to point to.
pja 12y ago
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.
- MrBuddyCasino 12y ago
  "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.
  - epochwolf 12y ago
    Per the article: If you have a OF/EFI firmware password set on the target Mac OS X, FireWire DMA is off by default.
bjackman 12y ago
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/ 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.
pgeorgi 12y ago
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)
j_s 12y ago
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 http://youtu.be/iTJApG0TMBQ?t=13m18s https://hn.algolia.com/?query=inception+firewire&sort=byDate&dateRange=all&type=story https://hn.algolia.com/?query=inception+firewire&sort=byDate...
thoughtsimple 12y ago
Scary in 2011. A little less so in 2012. As of now, not very scary.

72 points by deegles 12y ago

NKCSS 12y ago

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

aceperry 12y ago

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.

jannic 12y ago

"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?

lmm 12y ago
Any of the things in the "Attack mitigation" section.
- jannic 12y ago
  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.

lmm 12y ago

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

pja 12y ago

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.

MrBuddyCasino 12y ago
"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.
- epochwolf 12y ago
  Per the article: If you have a OF/EFI firmware password set on the target Mac OS X, FireWire DMA is off by default.

bjackman 12y ago

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/ 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.

pgeorgi 12y ago

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)

j_s 12y ago

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 http://youtu.be/iTJApG0TMBQ?t=13m18s https://hn.algolia.com/?query=inception+firewire&sort=byDate&dateRange=all&type=story https://hn.algolia.com/?query=inception+firewire&sort=byDate...

thoughtsimple 12y ago

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