I would like to see a live demo of this on a computer not of there choosing. My guess is there claim will come out false. Anyone and everyone can claim a lot, doing something for real takes a lot more.
I understand this is similar if not the same as a cold boot attack? If so woldn't the RAM be cleared and information lost after minutes of no power (shutdown)?
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
While it's good to know that there is software out there that can do this. Like a previous post mentioned lock the keychain, and simply reboot your Mac and then let let it go to sleep.
Also it would be a great idea for those that are really into security to change their admin/root password to something ultra hard to guess and figure out and put that password some place safe and forget about it.
Apple will get this and patch the issue. Another thing is this has to be performed at the unit level. Assuming using an external boot drive to be able to use this software on said machine. As a systems admin I can easily and quickly change the admin root password on a Mac, say someone gets terminated and leaves and their machine is locked, it's good to know and probably a really good tool to have in a tech's software toolbox, I know I wouldn't mind could come in handy some day.
For FireWire Macs, as of 10.7.2 apparently if your machine is locked (I assume in sleep or screen saver with password required on wake) you can't pull the password:
And as someone mentioned firmware password prevents all of this from happening in the first place.
So in my situation with FileVault 2 someone would need to access the memory while I am logged in AND not in sleep or screen saver. At which point they probably would have bashed me over the head and stolen my credit cards, since I usually flick to turn on the screen saver when I step away from the laptop or after 15 minutes. I do shut down the computer at night, usually because it's a ritual of "turning off work" before I go to sleep.
I'm assuming here Screen Saver locking is the same as Sleep locking, right? Someone please point out if it isn't.
But... I'm a little lost on the ease of recovering keychain passwords! Is this just an issue given the same issue above (no login password on sleep), or is it more universal?
Shutting down does provide better security for sure, but I thought the keychain should be secure from this type of attack.
If I understand you correctly, the attack is on the login password. Because once the attacker has that, they have FileVault unencrypted, and since your keychain is simply tied into your login once your login password is recovered your keychain is fully exposed, unless you have other keychains with separate logins ~ in which case not sure about *those* keychains.
But AFAIK your Login Keychain, ie. primary keychain is unlocked with your login password.
You can change your Login Keychain to have a different password but during regular use it is unlocked so that's accesible from the memory dump anyway.
Somebody correct me if I'm off track on this.
Firmware Password and FileVault2, Mac OS X 10.7.3 seems to be the best bet for most people. I don't use firmware password because I want a little wiggle room should something go quite wrong.
I understand this is similar if not the same as a cold boot attack? If so woldn't the RAM be cleared and information lost after minutes of no power (shutdown)?
Yes, it relates to Thunderbolt and FireWire having direct memory access for speed, hence access to memory dump of contents of memory. Once the whatever(?) is discharged upon shutdown the RAM should not have any content and this attack won't work.
Quote:
Originally Posted by Wings
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
That's an interesting point, I wonder if someone can comment. We're assuming without the keys saved in the keychain and upon unmounting OS X will scramble the memory space used to store those keys and whatever stuff they used to generate the DMG. Anybody?
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user?s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it?at least not without a quantum computer.
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user?s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it?at least not without a quantum computer.
Or a court order demanding you decrypt the drive
Or a thief with a hammer threatening to bash your skull in if you don't decrypt...
Maybe you'd better not carry house keys around with you, someone might rob you and break into your house.
One more reason not to use locks on your doors.
hmmm.. there is a log-in password (house keys if you like to call them like that). If someone force me to give the password (rob me when I am out taking a walk around) to bypass the logging-in/authentication (open the door of my house to break in), then it doesn't matter anymore whether file vault is on of off.
One more reason not to have a password (house keys) at all?! Really?!
Because you think it makes you less secure than ... what? Nothing at all?
Quote:
Originally Posted by astrubhar
This is a no-brainer. The OS needs to store the decryption key in memory or it wouldn't work. You should set a password that locks the keychain when you lock or sleep the Mac. What good is encryption if you're logged in and have full access to the drive anyways?
The idea here isn't that someone can snoop your RAM and get the key while the machine is running. That's plainly obvious, and is impossible to prevent (although the OS can make even that difficult, since you'd probably have to get your snooping process to run as root.)
The idea here is that when you put the machine to sleep, the keys are still in RAM, and can be snooped as long as nobody cuts power to the RAM. Requiring a password to get your desktop back doesn't matter, because the OS is able accessing the disk even before you've logged back in.
This can be fixed by the OS, however. It can discard/overwrite the keys as a part of going to sleep. The drive will no longer be accessible. Then you ask for the disk-decryption passphrase upon wakeup. During the time between when you request wakeup and enter the passphrase, even the OS won't be able to read the disk. Which should be fine, because (as far as the rest of the OS is concerned) the computer is still asleep at that time.
Quote:
Originally Posted by Ryzek
While it's good to know that there is software out there that can do this. Like a previous post mentioned lock the keychain, and simply reboot your Mac and then let let it go to sleep.
According to the article, that won't work for whole-disk encryption. If the OS has booted, then the keys are in memory. If they're not purged as a part of the sleep process (as the article claims) then your procedure won't change anything.
Note that this is not talking about the older FileVault's home-directory encryption. That's a completely different issue, and (as far as I know) those keys are discarded when the user logs out.
Quote:
Originally Posted by noirdesir
The point is not your encryption is 'unlocked' while you are logged into your account. It obviously is. No, the point is that one can glean the password from the content of the memory and then later decrypt the harddrive after it had been shut down.
Not after shutdown. After sleep. Nothing is going to be in memory after shutdown, because power is cut to the RAM. Some extraordinary measures involving extreme cold can preserve unpowered RAM content for a few minutes, but most people won't have to worry about that.
Quote:
Originally Posted by Wings
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
That should be OK, but there might be traces of the password in the freed memory pool, or corresponding parts of the swap file. Some operating systems make a point of zeroing-out freed memory to prevent attacks like this, but I don't know if Mac OS does this.
The lesson from this article is pretty simple. If you're in an untrusted place, shut down the computer when you're not actively using it. Don't just put it to sleep, because someone with forensic tools can bypass encryption if it's just asleep.
This is a no-brainer. The OS needs to store the decryption key in memory or it wouldn't 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.
Quote:
Originally Posted by realwarder
Waste of news article space...
Not really, they are storing all the passwords in plain-text, which is a bit silly.
Quote:
Originally Posted by williamh
Obfuscating the key would only work so long as nobody figures out how it was obfuscated.
Not entirely true, one-way hashing adds a sufficient level of security but they have to use that as the encryption key. It can still be used for decryption but not directly.
Quote:
Originally Posted by Wings
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
Yes and in plain-text but only while logged in. Logging out and flushing the processes clears the keys.
Quote:
Originally Posted by JiveTurkey
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user’s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
In some ways but FileVault 2 doesn't have any of the huge flaws in FV1. Mainly that if you put too many files in your home folder, you have to compress the disk image to get the space back again. Also, sparse images are more prone to corruption than fixed size images.
Quote:
Originally Posted by JiveTurkey
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it—at least not without a quantum computer.
Ideally both Filevault and manual encryption should be in use so that when powered down, a thief has no access to your data and when powered up shared users can't access your stuff. 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).
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.
This is a no-brainer. The OS needs to store the decryption key in memory or it wouldn't work. You should set a password that locks the keychain when you lock or sleep the Mac. What good is encryption if you're logged in and have full access to the drive anyways?
It's not only a "no-brainer" the whole situation seems unbelievably contrived as something they would have had to attempt to do, not stumble upon. What do I mean? It sounds like they tried every possible system preference and service setting in an effort to specifically access memory to get these "hints" (note: not even actual passwords) stored in memory. Add to that the fact that they are a Russian company and I smell something fishy at best. Is it a possible vulnerability? Sure. Is it a threat to 99.999999% of the FileVault using community, that, by-the-way understands that if you have FileVault turned on, you more than likely don't auto login to your system. Kinda defeats the purpose of FileVault. Apple just setting a system level flag to automatically (and uncontrollably) turn off auto login when FileVault is turned on should do the trick and take about 15 minutes to save that 0.000001% of the Mac OS X FileVault using community that MIGHT be affected. In other words:
NOTHING TO SEE HERE!!! Tempest in a tea cup. Mac OS X is so secure that the smallest irreducible crack affecting a ridiculously slim portion of a relatively small community gets the biggest hype...YAWN
The idea here is that when you put the machine to sleep, the keys are still in RAM, and can be snooped as long as nobody cuts power to the RAM. Requiring a password to get your desktop back doesn't matter, because the OS is able accessing the disk even before you've logged back in.
...
If you're in an untrusted place, shut down the computer when you're not actively using it. Don't just put it to sleep, because someone with forensic tools can bypass encryption if it's just asleep.
But it seems since 10.7.2 you can't snoop while logged in but in sleep mode... at least for this particular exploit:
Not to mention setting a firmware password makes this exploit impossible EVEN for logged-in, non-locked, non-sleep Macs. In fact, you don't have to set a firmware password, just disable FireWire DMA mode: http://translate.googleusercontent.c...8t295rwMT6Vjig
Yes, perhaps there are other forensic tools that can read the memory/drive if the Mac is asleep AND has FileVault2 AND firmware password set, but we haven't seen those in the wild yet, AFAIK.
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
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:
Not really, they are storing all the passwords in plain-text, which is a bit silly.
Yes, hopefully they will fix this part. But 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. But of course clear text reduces the attack from hours to seconds.
Quote:
Originally Posted by Marvin
Logging out and flushing the processes clears the keys.
Can they flush it automatically during sleep and screensaver-lock? That would be great, in addition to removing clear-text storage.
Quote:
Originally Posted by Marvin
In some ways but FileVault 2 doesn't have any of the huge flaws in FV1. Mainly that if you put too many files in your home folder, you have to compress the disk image to get the space back again. Also, sparse images are more prone to corruption than fixed size images.
Yes, I am very impressed with FileVault2. Wouldn't live without it. FileVault1 was risky and FileVault2 is a massive improvement, also because it renders your entire disk unreadable upon shutdown, if the disk is pulled from the Mac and plugged in somewhere else. It is also AFAIK used for Time Machine encryption, which is also handy if you lose your Time Machine backup. With FV1 IIRC there was no simple way to encrypt your Time Machine backup so if someone got hold of that drive all your data is available.
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).
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.
Ah... You answered some of our questions. No point going the 256 .DMG route if even after unmounting the password is still in memory.
Again it looks like things are not that bad, but Apple should firstly not store passwords in plain text in memory and flush everything upon sleep/ screensaver-lock/ logout/ etc.
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user?s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
Yes, I suppose with FV2 all other non-logged in users have their home folders unencrypted.
But assuming you lock down this FireWire exploit as suggested then when logged in someone has to run another exploit to get your user or another user's password, either with direct access to the Mac or over the (sub?)net. Such an exploit is not available in the wild for 10.7.2, right?
In any case what I do agree with you is that for multiple users on a Mac, really, really sensitive information should be stored as a 256 .DMG in their home folder, so when they are not logged in and assuming the DMG keys are flushed from memory that's inpenetrable.
So the steps recommended for now are the following:
1. Set firmware password
2. Use FileVault2 on internal drive AND TIME MACHINE DRIVE
3. Each user should have a 256 .DMG for really sensitive info***
4. Shut down when not in use, always Sleep or Lock Screen when stepping away from Mac
5. Set auto logout in System Prefs, screen saver after 15minutes with screen locking
***Currently investigating whether keys are flushed when unmounted
***UPDATE: WARNING: 256-bit AES ENCRYPTED DMG PASSWORDS ARE STORED IN PLAINTEXT IN MEMORY EVEN AFTER UNMOUNTING
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"
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user?s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it?at least not without a quantum computer.
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.
Again it looks like things are not that bad, but Apple should firstly not store passwords in plain text in memory and flush everything upon sleep/ screensaver-lock/ logout/ etc.
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.
Comments
english translation http://translate.google.com/translat..._2011-08-c.php
While it's good to know that there is software out there that can do this. Like a previous post mentioned lock the keychain, and simply reboot your Mac and then let let it go to sleep.
Also it would be a great idea for those that are really into security to change their admin/root password to something ultra hard to guess and figure out and put that password some place safe and forget about it.
Apple will get this and patch the issue. Another thing is this has to be performed at the unit level. Assuming using an external boot drive to be able to use this software on said machine. As a systems admin I can easily and quickly change the admin root password on a Mac, say someone gets terminated and leaves and their machine is locked, it's good to know and probably a really good tool to have in a tech's software toolbox, I know I wouldn't mind could come in handy some day.
For FireWire Macs, as of 10.7.2 apparently if your machine is locked (I assume in sleep or screen saver with password required on wake) you can't pull the password:
http://translate.googleusercontent.c...S6Hp-xXlZgRYzQ
And as someone mentioned firmware password prevents all of this from happening in the first place.
So in my situation with FileVault 2 someone would need to access the memory while I am logged in AND not in sleep or screen saver. At which point they probably would have bashed me over the head and stolen my credit cards, since I usually flick to turn on the screen saver when I step away from the laptop or after 15 minutes. I do shut down the computer at night, usually because it's a ritual of "turning off work" before I go to sleep.
I'm assuming here Screen Saver locking is the same as Sleep locking, right? Someone please point out if it isn't.
But... I'm a little lost on the ease of recovering keychain passwords! Is this just an issue given the same issue above (no login password on sleep), or is it more universal?
Shutting down does provide better security for sure, but I thought the keychain should be secure from this type of attack.
If I understand you correctly, the attack is on the login password. Because once the attacker has that, they have FileVault unencrypted, and since your keychain is simply tied into your login once your login password is recovered your keychain is fully exposed, unless you have other keychains with separate logins ~ in which case not sure about *those* keychains.
But AFAIK your Login Keychain, ie. primary keychain is unlocked with your login password.
You can change your Login Keychain to have a different password but during regular use it is unlocked so that's accesible from the memory dump anyway.
Somebody correct me if I'm off track on this.
Firmware Password and FileVault2, Mac OS X 10.7.3 seems to be the best bet for most people. I don't use firmware password because I want a little wiggle room should something go quite wrong.
I understand this is similar if not the same as a cold boot attack? If so woldn't the RAM be cleared and information lost after minutes of no power (shutdown)?
Yes, it relates to Thunderbolt and FireWire having direct memory access for speed, hence access to memory dump of contents of memory. Once the whatever(?) is discharged upon shutdown the RAM should not have any content and this attack won't work.
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
That's an interesting point, I wonder if someone can comment. We're assuming without the keys saved in the keychain and upon unmounting OS X will scramble the memory space used to store those keys and whatever stuff they used to generate the DMG. Anybody?
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it?at least not without a quantum computer.
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user?s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it?at least not without a quantum computer.
Or a court order demanding you decrypt the drive
Or a thief with a hammer threatening to bash your skull in if you don't decrypt...
Maybe you'd better not carry house keys around with you, someone might rob you and break into your house.
One more reason not to use locks on your doors.
hmmm.. there is a log-in password (house keys if you like to call them like that). If someone force me to give the password (rob me when I am out taking a walk around) to bypass the logging-in/authentication (open the door of my house to break in), then it doesn't matter anymore whether file vault is on of off.
One more reason not to have a password (house keys) at all?! Really?!
One more reason for me not to use file vault.
Because you think it makes you less secure than ... what? Nothing at all?
This is a no-brainer. The OS needs to store the decryption key in memory or it wouldn't work. You should set a password that locks the keychain when you lock or sleep the Mac. What good is encryption if you're logged in and have full access to the drive anyways?
The idea here isn't that someone can snoop your RAM and get the key while the machine is running. That's plainly obvious, and is impossible to prevent (although the OS can make even that difficult, since you'd probably have to get your snooping process to run as root.)
The idea here is that when you put the machine to sleep, the keys are still in RAM, and can be snooped as long as nobody cuts power to the RAM. Requiring a password to get your desktop back doesn't matter, because the OS is able accessing the disk even before you've logged back in.
This can be fixed by the OS, however. It can discard/overwrite the keys as a part of going to sleep. The drive will no longer be accessible. Then you ask for the disk-decryption passphrase upon wakeup. During the time between when you request wakeup and enter the passphrase, even the OS won't be able to read the disk. Which should be fine, because (as far as the rest of the OS is concerned) the computer is still asleep at that time.
While it's good to know that there is software out there that can do this. Like a previous post mentioned lock the keychain, and simply reboot your Mac and then let let it go to sleep.
According to the article, that won't work for whole-disk encryption. If the OS has booted, then the keys are in memory. If they're not purged as a part of the sleep process (as the article claims) then your procedure won't change anything.
Note that this is not talking about the older FileVault's home-directory encryption. That's a completely different issue, and (as far as I know) those keys are discarded when the user logs out.
The point is not your encryption is 'unlocked' while you are logged into your account. It obviously is. No, the point is that one can glean the password from the content of the memory and then later decrypt the harddrive after it had been shut down.
Not after shutdown. After sleep. Nothing is going to be in memory after shutdown, because power is cut to the RAM. Some extraordinary measures involving extreme cold can preserve unpowered RAM content for a few minutes, but most people won't have to worry about that.
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
That should be OK, but there might be traces of the password in the freed memory pool, or corresponding parts of the swap file. Some operating systems make a point of zeroing-out freed memory to prevent attacks like this, but I don't know if Mac OS does this.
The lesson from this article is pretty simple. If you're in an untrusted place, shut down the computer when you're not actively using it. Don't just put it to sleep, because someone with forensic tools can bypass encryption if it's just asleep.
This is a no-brainer. The OS needs to store the decryption key in memory or it wouldn't 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.
Waste of news article space...
Not really, they are storing all the passwords in plain-text, which is a bit silly.
Obfuscating the key would only work so long as nobody figures out how it was obfuscated.
Not entirely true, one-way hashing adds a sufficient level of security but they have to use that as the encryption key. It can still be used for decryption but not directly.
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
Yes and in plain-text but only while logged in. Logging out and flushing the processes clears the keys.
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user’s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
In some ways but FileVault 2 doesn't have any of the huge flaws in FV1. Mainly that if you put too many files in your home folder, you have to compress the disk image to get the space back again. Also, sparse images are more prone to corruption than fixed size images.
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it—at least not without a quantum computer.
Ideally both Filevault and manual encryption should be in use so that when powered down, a thief has no access to your data and when powered up shared users can't access your stuff. 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).
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.
This is a no-brainer. The OS needs to store the decryption key in memory or it wouldn't work. You should set a password that locks the keychain when you lock or sleep the Mac. What good is encryption if you're logged in and have full access to the drive anyways?
It's not only a "no-brainer" the whole situation seems unbelievably contrived as something they would have had to attempt to do, not stumble upon. What do I mean? It sounds like they tried every possible system preference and service setting in an effort to specifically access memory to get these "hints" (note: not even actual passwords) stored in memory. Add to that the fact that they are a Russian company and I smell something fishy at best. Is it a possible vulnerability? Sure. Is it a threat to 99.999999% of the FileVault using community, that, by-the-way understands that if you have FileVault turned on, you more than likely don't auto login to your system. Kinda defeats the purpose of FileVault. Apple just setting a system level flag to automatically (and uncontrollably) turn off auto login when FileVault is turned on should do the trick and take about 15 minutes to save that 0.000001% of the Mac OS X FileVault using community that MIGHT be affected. In other words:
NOTHING TO SEE HERE!!! Tempest in a tea cup. Mac OS X is so secure that the smallest irreducible crack affecting a ridiculously slim portion of a relatively small community gets the biggest hype...YAWN
The idea here is that when you put the machine to sleep, the keys are still in RAM, and can be snooped as long as nobody cuts power to the RAM. Requiring a password to get your desktop back doesn't matter, because the OS is able accessing the disk even before you've logged back in.
...
If you're in an untrusted place, shut down the computer when you're not actively using it. Don't just put it to sleep, because someone with forensic tools can bypass encryption if it's just asleep.
http://translate.googleusercontent.c...S6Hp-xXlZgRYzQ
Not to mention setting a firmware password makes this exploit impossible EVEN for logged-in, non-locked, non-sleep Macs. In fact, you don't have to set a firmware password, just disable FireWire DMA mode: http://translate.googleusercontent.c...8t295rwMT6Vjig
Yes, perhaps there are other forensic tools that can read the memory/drive if the Mac is asleep AND has FileVault2 AND firmware password set, but we haven't seen those in the wild yet, AFAIK.
What about a disk image with 256-bit AES encryption, created by Disk Utility? If it's not mounted, and the keys are never saved to the Keychain, are its keys also saved in RAM when not mounted?
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/
Not really, they are storing all the passwords in plain-text, which is a bit silly.
Yes, hopefully they will fix this part. But 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. But of course clear text reduces the attack from hours to seconds.
Logging out and flushing the processes clears the keys.
Can they flush it automatically during sleep and screensaver-lock? That would be great, in addition to removing clear-text storage.
In some ways but FileVault 2 doesn't have any of the huge flaws in FV1. Mainly that if you put too many files in your home folder, you have to compress the disk image to get the space back again. Also, sparse images are more prone to corruption than fixed size images.
Yes, I am very impressed with FileVault2. Wouldn't live without it. FileVault1 was risky and FileVault2 is a massive improvement, also because it renders your entire disk unreadable upon shutdown, if the disk is pulled from the Mac and plugged in somewhere else. It is also AFAIK used for Time Machine encryption, which is also handy if you lose your Time Machine backup. With FV1 IIRC there was no simple way to encrypt your Time Machine backup so if someone got hold of that drive all your data is available.
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).
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.
Ah... You answered some of our questions. No point going the 256 .DMG route if even after unmounting the password is still in memory.
Again it looks like things are not that bad, but Apple should firstly not store passwords in plain text in memory and flush everything upon sleep/ screensaver-lock/ logout/ etc.
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user?s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
Yes, I suppose with FV2 all other non-logged in users have their home folders unencrypted.
But assuming you lock down this FireWire exploit as suggested then when logged in someone has to run another exploit to get your user or another user's password, either with direct access to the Mac or over the (sub?)net. Such an exploit is not available in the wild for 10.7.2, right?
In any case what I do agree with you is that for multiple users on a Mac, really, really sensitive information should be stored as a 256 .DMG in their home folder, so when they are not logged in and assuming the DMG keys are flushed from memory that's inpenetrable.
So the steps recommended for now are the following:
1. Set firmware password
2. Use FileVault2 on internal drive AND TIME MACHINE DRIVE
3. Each user should have a 256 .DMG for really sensitive info***
4. Shut down when not in use, always Sleep or Lock Screen when stepping away from Mac
5. Set auto logout in System Prefs, screen saver after 15minutes with screen locking
***Currently investigating whether keys are flushed when unmounted
***UPDATE: WARNING: 256-bit AES ENCRYPTED DMG PASSWORDS ARE STORED IN PLAINTEXT IN MEMORY EVEN AFTER UNMOUNTING
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"
The full disk encryption of FileVault 2 is largely a step backwards from FileVault 1, as little sensitive information tends to be stored outside of a user?s Home folder and with FV2, simply using the computer in any way with any account means everything is unlocked and up for grabs. Zero security on a multi-user machine.
Just store your sensitive data on a 256-bit AES disk image with a strong 32-character passphrase that you dismount while not in use and no law enforcement (or any other) person will ever see it?at least not without a quantum computer.
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.
Again it looks like things are not that bad, but Apple should firstly not store passwords in plain text in memory and flush everything upon sleep/ screensaver-lock/ logout/ etc.
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.