See e.g. http://comments.gmane.org/gmane.linux.kernel.firewire.user/3981

In sleep mode the CPU is in a low power state, but it is still executing code.

The DMA part of firewire doesn’t need OS level drivers installed. It’s a function of the motherboard. Both Windows and Mac’s are vulnerable to the add-in card scenario, although only one current model of Mac even allows add-in cards, the laptops, iMacs and mac mini don’t.

For Mac’s with built-in firewire (and thunderbolt, that is vulnerable as well) the problem was fixed in 10.7.2 and DMA access is disabled on sleep. Not sure on Windows, but since Microsoft doesn’t make the PC hardware at the moment they may be more vulernable.

PGP is less vulnerable as long as your hibernation and page files are on encrypted volumes.  On sleep the key is erased from memory and the user must re-enter their password on wake before the drives can be used. If you use whole disk on your boot volume you’re probably ok.

More accurate info than Corey’s is available at Ars Technica: http://arstechnica.com/security/2012/12/cheap-app-cracks-pgp/ the comments in particular have some good info on this.

But maybe they aren’t talking about computers. Maybe they are talking about Macs. (ooh, burn) I’ve no idea what sort of stupid things Macs do when they are asleep or what stupid redefinition of “sleep” Apple uses, but if either are this fucked up, IMO it is just another one of the 92438765879436587 reasons to never use a Mac. Too much hand-holding and automagical system actions (like, say, polling for hardware changes and downloading and installing drivers, all while asleep, in the name of “Easy!”) leads to what we like to call gaping security holes.

I guess it makes sense if “asleep” means “powered off and hibernating”, provided you can wake the machine up from hibernation without requiring a password?

In the real world, if you care about securing your computer, you can already store the key off-board AND require a HW backed PIN that is quite robust. You can do this for hibernate if you like standby but are worried about security. And BitLocker wipes memory *even on an unplanned power-down* so you’re covered there too.

I wrote about the basics of this WAAAAAAY back in 2008: 

http://peternbiddle.wordpress.com/2008/02/22/attack-isnt-news-and-there-are-mitigations/

Also note that we developed an additional cipher for BitLocker that makes grinding out the PW check auth code extremely difficult by adding cross-block-level randomness to the disk so you can’t reboot over and over again and look for diffs and try to find the registry setting requiring PWs a midst a sea of random. 

Also on my machine, installation of admin-privileged code (that includes DMA driver updates and replacement of PW code, last I checked) requires a user confirmation, which a device isn’t going to be able to do… not unless it is also somehow replacing the mouse driver. Which would require user auth. 
What am I missing here? How do you get past UAC? 
Which it’s recursive, innit? 

The scarier possibility here, is that DMA access allows for arbitrary code execution, which allows for patching arbitrary firmware of any chipset or device on the machine, permanently compromising the device even if the filesystems are entirely replaced.

What gets me is that the target machine can successfully load drivers etc while sleeping. Surely “sleep” means “don’t do any processing and keep memory state static” ?

If my reading is correct, the cool part of this attack is not the ability to stub out the password verification step(being able to do so with just a firewire cable is certainly nice, and more elegant than popping out the drive and then either reading what you want on a different system or overwriting the locally stored password hashes and logging in that way); but the fact that, if the computer is sleeping, the secret key that allows decryption of an encrypted filesystem is protected only by the (breakable) password verification step, rather than actually requiring knowledge of the password, as it would if you were cold booting.

In an ideal world, the sleeping system would not actually be storing the decryption key at all, only enough to infer it with access to the real password(so, even if the attacker stubbed out verification, they’d still get a garbage decryption key unless they used the correct password).

That would make things significantly more complex, since the system would have to have enough unencrypted components to wake from sleep and ask for credentials without panicking horribly; but not so many unencrypted components that useful fragments of user information could be gathered; but if it were possible it would also reduce the DMA attacks to a merely more convenient flavor of ‘just pop out the HDD’ attack…

Also: glad I got the cheaper laptop without expansion slots!

The demand for hot-pluggable external ports on computers that are kept outside physically secure environments makes this hitherto largely theoretical problem a more serious concern(ISA and PCI were also vulnerable, in the ages when dinosaurs wandered the earth; but you’d notice before somebody screwdrivered open your IBM PC and popped a malicious card in, even assuming that that wouldn’t kill the motherboard…); but it isn’t as though this is an abberation of some kind in a single standard; DMA shows up in a great many high speed(or high speed for their time) interfaces because it is good at what it does.

Edit: Forgive my laziness, I’m trying to find an article now.
http://www.tomshardware.com/reviews/usb-firewire-esata,2534-6.html <- There. A year-1995 technology still beating a year-2000 technology, while taking up less CPU cycles.