The passwords aren't in plaintext, the keys are in binary, but that's what you need, the binary key. And given physical access to the raw memory while the computer is on and logged in, there are ways to identify the binary key.
The passwords are plaintext. Both for user password and below, testing of an *unmounted* 256 DMG.
To answer my own question (I think), I see where an encrypted disk image is not vulnerable to this type of exploit while the image is unmounted, even if the computer is left powered on. Hey, I read this on the internet so it must be good info. Here:
***Update: Warning: FILEVAULT2 external drive encrypted passwords are stored in plaintext in memory even after unmounting
***Update: Warning: 1Password master password for that app is stored in plaintext in memory
If they have physical access to a machine, it would appear the first thing an attacker would do is dump all the memory into a USB drive. Then go off and have fun reading all the passwords and stuff. So not just existing data on the computer is accessible but other data (web passwords perhaps?) can be read.
I'm wondering as well with RAM cached to disk. Upon restarting the machine, does some of that cached RAM stored on the hard drive get "put back" into active RAM? Hence re-loading exposed data into RAM even after restart/ shut down/ etc.
Again, keep in mind disabling FireWire DMA disables all the green stuff below completely, and disabling Fast User Switching during screensaver lock is quite effective:
For sleep, you can flush the keys manually and force hibernating:
"destroyfvkeyonstandby \t1 \tRemoves the full volume encryption key from RAM when the system is put into sleep mode and is dependent on the value of hibernatemode.
hibernatemode \t25 \tForces the system to immediately write RAM to disk and remove power from memory upon sleep.
For example:
sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25"
Indeed very informative article! Ty for posting.
I for one never had fast user switching enabled, and had screen lock after 5 min of innactivity. That should do it. Also have FV2 and Firmware password installed. I never use sleep, and i always shut down the computer at the end of the day or when i finish work
There could be an option to dump the memory to disk in a sleepimage on logout, flush the RAM and unmount the encrypted drive leaving only a basic app to process the input password, remount the drive and restore the OS. It would make the logout process slow and it wouldn't work for multiple users but it's an option.
You can do this when going to sleep. You can't do it on logout, because system tasks continue to run in the background even when logged off. They will still need file system access.
Quote:
Originally Posted by Marvin
But Apple leaves the keys for mounted encrypted volumes in RAM after they are unmounted - only flushes them when you kill a certain process (not sure which one though).
I doubt this is deliberate. Disk images are (IIRC) mounted by Disk Utility, which the Finder launches in the background when you double-click on a DMG file. If, when you unmount, DU doesn't quit (perhaps because there are other mounted volumes, or maybe in order to speed up subsequent re-mounts) then it is possible for the keys to remain in memory. If the code simply frees the allocated memory, the data may remain until some other activity causes the RAM to be overwritten. DU should overwrite the memory with zeros before freeing it.
I don't think there's a need to keep the key encrypted in RAM while the image is mounted, since anyone trying to access the data could just access the mounted volume.
Quote:
Originally Posted by Marvin
For the time being, I'll keep my sensitive documents under my mattress.
Personally, I don't care. I don't keep anything sensitive on my laptop.
Quote:
Originally Posted by Marvin
EDIT: seems like the solution might be to force-quit the daemon diskarbitrationd (it will get a new process id) and then purge inactive memory (Xcode comes with a tool called purge). This won't work for admin passwords, just encrypted volume keys but the admin passwords just need to be hashed.
Thanks. So I got the process name wrong, but it appears that my analysis is still correct. This specific problem (involving disk images, not File Vault 2) should be easily fixable.
Quote:
Originally Posted by Hiro
Except when the whole disk is encrypted it hides how much of that is critical data, how much is routine noise data and how much is free space. There is value in that.
Well, someone looking at the size of the encrypted home directory will know how much stuff you have stored. He won't know how much of it is critical data. I may have one critical document and 50GB of my iTunes music collection in there.
according to one of the websites linked to above, even if it is stored as hashes simpler passwords can be brute-force/etc. attacked quite easily.
It depends on how it's done. You can pass the hash through as many times as you like so if someone tries to brute force the hash they see in RAM, they won't get your password because a hash result was used to generate it. If they figured out the process Apple used to create the hash, they could brute force it and without a salt, generate a lookup table but Apple just has to use random salts and make the hash process slow. Apple only does it once, brute force requires someone to do it many billions of times over.
Quote:
Originally Posted by nvidia2008
Can they flush it automatically during sleep and screensaver-lock? That would be great, in addition to removing clear-text storage.
They should be able to do it as soon as you have mounted the volume.
Quote:
Originally Posted by nvidia2008
Upon restarting the machine, does some of that cached RAM stored on the hard drive get "put back" into active RAM? Hence re-loading exposed data into RAM even after restart/ shut down/ etc.
VM caches are flushed on reboot but of course the old VM caches aren't overwritten so plain text passwords that went into RAM and were paged to the drive will exist in your deleted files until overwritten. You could for example sell on an old computer that has a trace of your plain text passwords for your encrypted drives - hence why you should always zero the drive.
Quote:
Originally Posted by shamino
I don't think there's a need to keep the key encrypted in RAM while the image is mounted, since anyone trying to access the data could just access the mounted volume.
It depends on the attack that's being used. Say you were a rival company to Apple (e.g Samsung) and wanted to steal all the upcoming designs. You wouldn't try to copy GBs over the network while the drive was mounted, you'd send a trojan that installs as root and scan the RAM for plain text keys.
Then you'd either do a physical theft of the drives and be able to unlock them easily or unlock them at your leisure via a remote command, most likely when the systems were not in use.
Quote:
Originally Posted by shamino
This specific problem (involving disk images, not File Vault 2) should be easily fixable.
It should be but I think they should encrypt volumes using hashed keys, which would require the encryption to be re-applied.
I for one never had fast user switching enabled, and had screen lock after 5 min of innactivity. That should do it. Also have FV2 and Firmware password installed. I never use sleep, and i always shut down the computer at the end of the day or when i finish work
VM caches are flushed on reboot but of course the old VM caches aren't overwritten so plain text passwords that went into RAM and were paged to the drive will exist in your deleted files until overwritten. You could for example sell on an old computer that has a trace of your plain text passwords for your encrypted drives - hence why you should always zero the drive.
Ah, interesting. Well, that's a point in favour of whole-disk encryption. FileVault2 would ensure someone that pulled the drive would not be able to read old VM caches even if the drive had not been zero'd.
I don't think I'd ever work with unencrypted drives ever again, given what I know now. I did have some fairly old hard disks and I just opened it up and smashed the platters. I guess 7-pass erase or whatever would've been less "physical" LOL. I think I didn't have the patience. Plus it's interesting seeing the innards of a modern hard drive. And to think it's old hat now. Spinning physical media... So '00s
I use an encrypted disk image to protect my sensitive files (tax returns, bank account details etc). Never saw any need to encrypt my whole HD.
Am quite disappointed with Apple if they don't remove the password from memory upon eject. They need a special version of free() which zeroes out, and a way to flag certain NSObjects as needing this, and have ARC honor it.
I for one never had fast user switching enabled, and had screen lock after 5 min of innactivity. That should do it. Also have FV2 and Firmware password installed. I never use sleep, and i always shut down the computer at the end of the day or when i finish work
Also, it turns out that both the Passware tool and Inception works over Thunderbolt daisy chaining as well. This opens up the possibility of being hacked when connecting to a Thunderbolt device, such as a hard drive or a Thunderbolt display. Since the FileVault2 DMA protection only is in effect when the OS is locked, the DMA attacks will essentially work if performed covert while the machine is unlocked.
The same restrictions as mentioned in the frameloss.org article and the posts above apply.
Also, it turns out that both the Passware tool and Inception works over Thunderbolt daisy chaining as well. This opens up the possibility of being hacked when connecting to a Thunderbolt device, such as a hard drive or a Thunderbolt display. Since the FileVault2 DMA protection only is in effect when the OS is locked, the DMA attacks will essentially work if performed covert while the machine is unlocked.
Thunderbolt is effectively a PCI Express slot. It has all the same vulnerabilities that could be exploited against a card installed in a Mac Pro's PCIe slot. If you attach an untrusted device, then it can access absolutely everything in the computer.
IT security departments should make a point of letting users know about this, if they think it is a serious concern.
That page also provides the crucial information that DMA can be turned off by setting a Firmware password for your Mac. (I've been using Filevault2 in lieu of a firmware password, but now I know to use both. What I don't know is that the performance hit will be by disabling DMA.
Comments
The passwords aren't in plaintext, the keys are in binary, but that's what you need, the binary key. And given physical access to the raw memory while the computer is on and logged in, there are ways to identify the binary key.
The passwords are plaintext. Both for user password and below, testing of an *unmounted* 256 DMG.
sudo ./MacMemoryReader ~/Desktop/ram_dump.mach-o
grep -abo canthackthis ~/Desktop/ram_dump.mach-o
585965363:canthackthis
1207265562:canthackthis
2025878541:canthackthis
^C
To answer my own question (I think), I see where an encrypted disk image is not vulnerable to this type of exploit while the image is unmounted, even if the computer is left powered on. Hey, I read this on the internet so it must be good info. Here:
http://reviews.cnet.com/8301-13727_7...-via-firewire/
***UPDATE: WARNING: 256-bit AES ENCRYPTED DMG PASSWORDS ARE STORED IN PLAINTEXT IN MEMORY EVEN AFTER UNMOUNTING
The Cnet article is incorrect. See my test in the post above.
***Update: Warning: 1Password master password for that app is stored in plaintext in memory
If they have physical access to a machine, it would appear the first thing an attacker would do is dump all the memory into a USB drive. Then go off and have fun reading all the passwords and stuff. So not just existing data on the computer is accessible but other data (web passwords perhaps?) can be read.
I'm wondering as well with RAM cached to disk. Upon restarting the machine, does some of that cached RAM stored on the hard drive get "put back" into active RAM? Hence re-loading exposed data into RAM even after restart/ shut down/ etc.
Interesting.
Here's a good article: http://www.frameloss.org/2011/09/18/...-2-encryption/
Again, keep in mind disabling FireWire DMA disables all the green stuff below completely, and disabling Fast User Switching during screensaver lock is quite effective:
For sleep, you can flush the keys manually and force hibernating:
"destroyfvkeyonstandby \t1 \tRemoves the full volume encryption key from RAM when the system is put into sleep mode and is dependent on the value of hibernatemode.
hibernatemode \t25 \tForces the system to immediately write RAM to disk and remove power from memory upon sleep.
For example:
sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25"
Indeed very informative article! Ty for posting.
I for one never had fast user switching enabled, and had screen lock after 5 min of innactivity. That should do it. Also have FV2 and Firmware password installed. I never use sleep, and i always shut down the computer at the end of the day or when i finish work
There could be an option to dump the memory to disk in a sleepimage on logout, flush the RAM and unmount the encrypted drive leaving only a basic app to process the input password, remount the drive and restore the OS. It would make the logout process slow and it wouldn't work for multiple users but it's an option.
You can do this when going to sleep. You can't do it on logout, because system tasks continue to run in the background even when logged off. They will still need file system access.
But Apple leaves the keys for mounted encrypted volumes in RAM after they are unmounted - only flushes them when you kill a certain process (not sure which one though).
I doubt this is deliberate. Disk images are (IIRC) mounted by Disk Utility, which the Finder launches in the background when you double-click on a DMG file. If, when you unmount, DU doesn't quit (perhaps because there are other mounted volumes, or maybe in order to speed up subsequent re-mounts) then it is possible for the keys to remain in memory. If the code simply frees the allocated memory, the data may remain until some other activity causes the RAM to be overwritten. DU should overwrite the memory with zeros before freeing it.
I don't think there's a need to keep the key encrypted in RAM while the image is mounted, since anyone trying to access the data could just access the mounted volume.
For the time being, I'll keep my sensitive documents under my mattress.
EDIT: seems like the solution might be to force-quit the daemon diskarbitrationd (it will get a new process id) and then purge inactive memory (Xcode comes with a tool called purge). This won't work for admin passwords, just encrypted volume keys but the admin passwords just need to be hashed.
Thanks. So I got the process name wrong, but it appears that my analysis is still correct. This specific problem (involving disk images, not File Vault 2) should be easily fixable.
Except when the whole disk is encrypted it hides how much of that is critical data, how much is routine noise data and how much is free space. There is value in that.
Well, someone looking at the size of the encrypted home directory will know how much stuff you have stored. He won't know how much of it is critical data. I may have one critical document and 50GB of my iTunes music collection in there.
according to one of the websites linked to above, even if it is stored as hashes simpler passwords can be brute-force/etc. attacked quite easily.
It depends on how it's done. You can pass the hash through as many times as you like so if someone tries to brute force the hash they see in RAM, they won't get your password because a hash result was used to generate it. If they figured out the process Apple used to create the hash, they could brute force it and without a salt, generate a lookup table but Apple just has to use random salts and make the hash process slow. Apple only does it once, brute force requires someone to do it many billions of times over.
Can they flush it automatically during sleep and screensaver-lock? That would be great, in addition to removing clear-text storage.
They should be able to do it as soon as you have mounted the volume.
Upon restarting the machine, does some of that cached RAM stored on the hard drive get "put back" into active RAM? Hence re-loading exposed data into RAM even after restart/ shut down/ etc.
VM caches are flushed on reboot but of course the old VM caches aren't overwritten so plain text passwords that went into RAM and were paged to the drive will exist in your deleted files until overwritten. You could for example sell on an old computer that has a trace of your plain text passwords for your encrypted drives - hence why you should always zero the drive.
I don't think there's a need to keep the key encrypted in RAM while the image is mounted, since anyone trying to access the data could just access the mounted volume.
It depends on the attack that's being used. Say you were a rival company to Apple (e.g Samsung) and wanted to steal all the upcoming designs. You wouldn't try to copy GBs over the network while the drive was mounted, you'd send a trojan that installs as root and scan the RAM for plain text keys.
Then you'd either do a physical theft of the drives and be able to unlock them easily or unlock them at your leisure via a remote command, most likely when the systems were not in use.
This specific problem (involving disk images, not File Vault 2) should be easily fixable.
It should be but I think they should encrypt volumes using hashed keys, which would require the encryption to be re-applied.
Indeed very informative article! Ty for posting.
I for one never had fast user switching enabled, and had screen lock after 5 min of innactivity. That should do it. Also have FV2 and Firmware password installed. I never use sleep, and i always shut down the computer at the end of the day or when i finish work
Cheers... Well, sounds like you have it covered!
VM caches are flushed on reboot but of course the old VM caches aren't overwritten so plain text passwords that went into RAM and were paged to the drive will exist in your deleted files until overwritten. You could for example sell on an old computer that has a trace of your plain text passwords for your encrypted drives - hence why you should always zero the drive.
Ah, interesting. Well, that's a point in favour of whole-disk encryption. FileVault2 would ensure someone that pulled the drive would not be able to read old VM caches even if the drive had not been zero'd.
I don't think I'd ever work with unencrypted drives ever again, given what I know now. I did have some fairly old hard disks and I just opened it up and smashed the platters. I guess 7-pass erase or whatever would've been less "physical" LOL. I think I didn't have the patience. Plus it's interesting seeing the innards of a modern hard drive. And to think it's old hat now. Spinning physical media... So '00s
Am quite disappointed with Apple if they don't remove the password from memory upon eject. They need a special version of free() which zeroes out, and a way to flag certain NSObjects as needing this, and have ARC honor it.
Indeed very informative article! Ty for posting.
I for one never had fast user switching enabled, and had screen lock after 5 min of innactivity. That should do it. Also have FV2 and Firmware password installed. I never use sleep, and i always shut down the computer at the end of the day or when i finish work
Hey guys, this may interest you: I've developed an open source tool that are able to facilitate the same functionality as the Passware tool. It is called Inception, and you can check it out here.
/shameless plug
Also, it turns out that both the Passware tool and Inception works over Thunderbolt daisy chaining as well. This opens up the possibility of being hacked when connecting to a Thunderbolt device, such as a hard drive or a Thunderbolt display. Since the FileVault2 DMA protection only is in effect when the OS is locked, the DMA attacks will essentially work if performed covert while the machine is unlocked.
The same restrictions as mentioned in the frameloss.org article and the posts above apply.
Also, it turns out that both the Passware tool and Inception works over Thunderbolt daisy chaining as well. This opens up the possibility of being hacked when connecting to a Thunderbolt device, such as a hard drive or a Thunderbolt display. Since the FileVault2 DMA protection only is in effect when the OS is locked, the DMA attacks will essentially work if performed covert while the machine is unlocked.
Thunderbolt is effectively a PCI Express slot. It has all the same vulnerabilities that could be exploited against a card installed in a Mac Pro's PCIe slot. If you attach an untrusted device, then it can access absolutely everything in the computer.
IT security departments should make a point of letting users know about this, if they think it is a serious concern.
Quote:
Originally Posted by carmaa
Hey guys, this may interest you: I've developed an open source tool that are able to facilitate the same functionality as the Passware tool. It is called Inception, and you can check it out here.
That is is terrific.
That page also provides the crucial information that DMA can be turned off by setting a Firmware password for your Mac. (I've been using Filevault2 in lieu of a firmware password, but now I know to use both. What I don't know is that the performance hit will be by disabling DMA.
Cheers,
-j