[1] https://support.apple.com/kb/HT5002
(missed the note about this on the page the first time through, but I'm leaving this for others who may have missed it)
How does this work in OSX if a Firewire device is in the middle of a DMA operation when the OS is locked? Does the operation fail? Does the user lose data?
No driver, no workey.
For Firewire. What about for Thunderbolt?
http://www.reddit.com/r/netsec/comments/15ydem/inception_is_...
[1]: http://www.breaknenter.org/2012/02/adventures-with-daisy-in-...
Physical Access == Game Over
There's no good reason why this vulnerability still exists after 10 years except a failed design, laziness on the part of OS developers and that security professionals in general meet the problem with the above statement that "physical access equals compromise".
I think end users deserve (and expect) secure devices, even when physical access is lost. I realize that it's harder to protect a physical device, but it's not impossible.
Physical access == compromise even for devices that are as simple as a hollow metal box.
http://en.wikipedia.org/wiki/Safe
Security ratings for those devices are measured in time. Basically, if you lose possession, it's just a matter of time. Digital security is both easier and harder, because all you're protecting there is information. If you wish for the information to be destroyed on tampering, then your job may be easier.
The only way for there to be hardening when physical access is lost is to have some form of layered defense in depth, the aim being giving the user enough time to send a command to wipe the device.
I'll give you that, but there are too many kinds of physical access attacks to even consider aiming at solving the entire class of attacks.
> Physical access should not equal compromise.
And I want a million dollars. Guess which one's more likely.
If someone is trusted to get access to the actual device then it's pretty much game over. Do you check the keyboard cables for key-capture hardware? Do you check for all the other nefarious devices? Do you check your OS has not been tampered with?
Basically it's the same problem as DRM that actually works.
Companies are issuing disposable laptops, iPads, and cell phones to employees traveling to Asia. Consider why that might be.
Edit: May not have been inception, but something similar... I remember unlocking Windows XP laptops!
Check out the attack device we implemented and how we defend against it: http://www.privatecore.com/dma-attack-video.html
More than a few organizations shove hot glue into USB ports to secure the machine.
It's hard enough to get machines secure from drive-by web browsing attacks. Getting them safe from physical access is substantially, substantially harder.
Open machine and plug unglued USB connector to the motherboard. It is probably not that difficult to unglue the connector with a heat gun and some pliers or something.
And you don't really need something as tailored as a new BIOS chip, in most cases where you can boot from USB/Firewire/whatever you can just replace the bootloader with one that copies the password as you enter it.
That's why you might want to have your bootloader on a USB stick or something that isn't available to the attacker even if he/she gets physical access.
But that of course doesn't protect someone from altering the BIOS (or even, the firmware of your keyboard...). But it at least usually requires more effort.
Or, one could be listening in by targeting a laser on a window nearby (and watch the reflections as the sound-waves propagate through the glass) and listen to your keystrokes, and based on statistics (gathered when you write HN posts ;)) figure out your password without even getting in the same room as the hardware.
If someone has the resources and motivation to get your data he/she will probably be able to :(
Goes for anything else you "own." The real question is, how bad do they want it, what are the economics, and how does society at large feel about it?
But bypassing or stealing password or key for cold, non-mounted volume is impossible: for example, TrueCrypt volume is mathematically indistinguishable from /dev/urandom output until exact password is provided.
Walk over the process list in memory, and find one that's got good privileges but stays asleep. Patch its code to call mount (anywhere's fine, maybe in the heap, or if it's asleep in sys_read, in the destination buffer), alter the saved IP in the task table to the mount call, and (this may be the tricky part) move it to a CPU's ready-task list.
After mount, play the same trick to run an executable, and change it's UID to root. Hell it can just spin in a get UID/sleep() loop until it's ready. Then you've got all of root-userland to do what you need. That can include installing keyboard sniffers that save the last kilobyte or so, which is saved or transmitted when the right entry point into the encrypted-mount path is hit.
Were these kinds of exploits noted when writing the 1394 spec and ignored in favour of the DMA feature?
Hopefully that'll get better.
http://www.reddit.com/r/netsec/comments/15ydem/inception_is_...
