MBA fails to wake (Platform Failure) after entering Low Power Sleep state

@cmeid

What do you think of my findings?

What do the others think?

Hey Spacemarine,

sorry not to have gotten back to you earlier, I've been having a very busy week at work.

I think that the man page is definitely unclear to a degree, but the behavior seems to follow what one would expect.

Now, your findings with sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 25 standby 1 standbydelay 20 seem to me to be the behavior you want, right? You want to always have to enter a password to unlock the disk?

Now if we assume that "destroyfvkeysonhibernate 0" really means that the keys get written to a permanent location in plaintext before the system suspends to disk, then all of the bevaviour could be explained. But this would be highly insecure!!!

I think we can definitely assume that, so I think the behavior makes sense. Sure, setting DestroyFVKeyOnStandby to 0 is insecure, but every system has options that can make it insecure. So we set it to 1 and enjoy our security.

You probably don't want to set FEATURE(promiscuous_relay) on sendmail either, but there's no reason not to have the option. Such options are critical if you're doing development testing of features like this. A friend of mine, for example, develops kernel modules that interact with these functions. For him, being able to turn off something like key deletion is a good thing and an important thing. Of course, on a regular user system DestroyFVKeyOnStandby should always be set to 1, which I believe Apple does do by default.

As far as your testing, I would be curious whether setting standby to 0 would make the hibernation (in mode 25) work instantaneously for you rather than with a 20 second delay. On the other hand, it can also be pretty convenient if you remember something else you wanted to do on the computer before it hibernates to have a short grace period before you need two passwords to unlock it.

Thoughts?

cmeid

Now, your findings with sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 25 standby 1 standbydelay 20 seem to me to be the behavior you want, right? You want to always have to enter a password to unlock the disk?

No, I'm using hibernatemode 0, because I want two things: 1. The content of the RAM must never get written to disk in plaintext. 2. I don't want to enter my decryption password on every wake up, as this takes too much time (over 30 characters). Since the screen is protected by my short user password and the RAM can not be removed from the motherboard easily, this gives me reasonable security with no drawback in comfort.

Of course, on a regular user system DestroyFVKeyOnStandby should always be set to 1, which I believe Apple does do by default.

Are you sure that the default is 1? I think it's set to 0 and thats really dangerous. After I activated FV2, I observed that I did now have to input my decryption password, that's what made me suspicious. Since I didn't change anything with DestroyFVKeyOnStandby back then, I guess the default option is 0.

No, I'm using hibernatemode 0, because I want two things: 1. The content of the RAM must never get written to disk in plaintext. 2. I don't want to enter my decryption password on every wake up, as this takes too much time (over 30 characters). Since the screen is protected by my short user password and the RAM can not be removed from the motherboard easily, this gives me reasonable security with no drawback in comfort.

So was sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 0 standby 1 standbydelay 20 the setting you went with, or which one did you pick?

Do you mostly use your macine on AC? Even as the most secure setting, your setup would be impractical for me because I use the machine on battery so much.

Now, I'm comfortable making that security tradeoff because I'm more worried about keeping my data out of the hands of casual laptop theives than keeping it away from LE or intelliegence agencies.

Are you sure that the default is 1? I think it's set to 0 and thats really dangerous. After I activated FV2, I observed that I did now have to input my decryption password, that's what made me suspicious. Since I didn't change anything with DestroyFVKeyOnStandby back then, I guess the default option is 0.

I am quite certain that it was set to 1 by default on my machine - I still have the output of pmset saved from before I ever changed anything and I just checked it. (Mid 2011 11" Air)

Now, the man page says:

destroyfvkeyonstandby - Destroy File Vault Key when going to standby mode. By default File vault keys are retained even when system goes to standby. If the keys are destroyed, user will be prompted to enter the password while

coming out of standby mode.(value: 1 - Destroy, 0 - Retain)

Unfortunately the usage of sleep, standby and hibernate is not entirely consistent in the man page, I'm not 100% sure whether they're talking about sleep or hibernate but I think it actually is hibernate. This would indicate a default of 0, though, as I say, I'm 100% certain that DestroyFVKeyOnStandby was set to 1 on my box by default, because I still have that initial pmset output.

So was sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 0 standby 1 standbydelay 20 the setting you went with, or which one did you pick?

Yes, I'm using that at the moment. But since hibernatemode is 0, the other options shouldn't matter. That's why I didn't mention them.

My MBA is nearly always on AC when I'm home. And when I'm not home, I usually don't need it for more than a few hours and can charge every night. So the drain (about 10% per day) is not really relevant to me.

I can check the default setting tomorrow at a friends MBA, who hasn't changed this setting. For apple's sake I hope it's 1. 🙂

I'm also not afraid of LE or intelligence agencies, but I guess it's just the same kind of motivation that drives people to by a SUV. Of course you don't need it, but it's nice to know you could if you needed to... And in comparison to an SUV it doesen't have any drawbacks.

I'm refering to the results you posted:

sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 3 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: regular screen unlock

On battery, reopening the lid after 30 s: asks for gray decryption password, then regular screen unlock

On AC, reopening the lid after 15 s: regular screen unlock

On AC, reopening the lid after 30 s: regular screen unlock --> this is unexpected, maybe ram is not cleared on AC?

NOT UNEXPECTED AT ALL! The RAM wasn't intended to be cleard in all 4 cases.

hibernatemode 3 does copy the RAM to the hard drive, but it only powers off RAM when the battery is totally drained. In other words, when the system has absolute no power at all. This of cause will never appear while on AC. So if there is a little bit of battery life left the system will boot from the RAM just because of the faster wakeup time, even as it has already made the copy the hard drive, as a "backup" in case the battery will be drained completly befor the next wake up.

see under "man pmset":

"hibernatemode = 3 (binary 0011)" ... "The system will store a copy of memory to persistent storage (the disk), and will power memory during

sleep. The system will wake from memory, unless a power loss forces it to restore from disk image."

--> The problem I have is that your result differ from that I get from my system and the do only differ at this scenario:

On battery, reopening the lid after 30 s: regular screen unlock

On AC, reopening the lid after 30 s: regular screen unlock

So my system doesn't seem to execute the command destroyfvkeyonhibernate 1 when combined with hibernatemode 3.

Would be great to find the reason why it won't overwrite the key in the RAM while using the "data loss protection" which equals hibernatemode 3

Are you sure that the OS "asks for gray decryption password, then regular screen unlock while on battery after you reopened the lid after 30 s" ?

The same reason explains why the following ISN'T UNEXPECTED EITHER:

sudo pmset -a destroyfvkeyonhibernate 0 hibernatemode 3 standby 1 standbydelay 20

On battery, reopening the lid after 15 s: regular screen unlock

On battery, reopening the lid after 30 s: regular screen unlock -> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

On AC, reopening the lid after 15 s: regular screen unlock

On AC, reopening the lid after 30 s: regular screen unlock --> this is unexpected, either the key is saved somewhere in plaintext or ram isn't cleared

As above the RAM wasn't intended to be cleard in all 4 cases.

By the way my MBA never failed to wake after entering Low Power Sleep state.

And the other thing is a had to use the command "destroyfvkeyonstandby" instead of "destroyfvkeyonhibernate", cause my system doesn't know that command at all. I could perform all your scenarios without creating a second user.

I created a second user about 3 months ago to fix the "Lion-wifi-bug", but deleted it only minutes after I fixed it.

Here is the link to that:

Re: WiFi Issues With MacBook Air

Spacemarine wrote:

Now, your findings with sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 25 standby 1 standbydelay 20 seem to me to be the behavior you want, right? You want to always have to enter a password to unlock the disk?

No, I'm using hibernatemode 0, because I want two things: 1. The content of the RAM must never get written to disk in plaintext. 2. I don't want to enter my decryption password on every wake up, as this takes too much time (over 30 characters). Since the screen is protected by my short user password and the RAM can not be removed from the motherboard easily, this gives me reasonable security with no drawback in comfort.

wrong. you're completely mistaken about that providing anything but a false sense of security. An attacker could extract the contents of RAM via your thunderbolt port the same way the attack was preformed via firewire at blackhat conference last year.

What's sickening is that the one configuration that would provide real security.. requriing you to enter both passwords on wakeup... seems to be broken.

If anyone can show me a setting that does not store the password as cleartext on disk and removes power from the ram, and requires the disk crypto password on wakeup.. then you'll have solved my problem and we'll have a secure setting to use. I think apple intentionally broke the only secure setting, probably as some sort of deal with homeland security or whatever.

You are absolutly right triumph1337, forgot to mention that yesterday.

Spacemarine's MBA isn't secured at all, though the data is "encrypted" he gives away his "desired protection" by using the good old sleepmode (system powered down exept of the RAM), which is hibernatemode 0.

The only secured mode by actual result would be the hibernatemode 25, where the system completly powers down as soon as the copying process of the RAM to the disc is completed:

sudo pmset -a destroyfvkeyonhibernate 1 hibernatemode 25 standby 1 standbydelay 20

A 20 seconds delay should be a good compromise for providing oneself a time frame long enough for aborting the hybernationsleep and onther other side short enough to ensecure the complet system will be definitle powerded off in the case that some thieve grabs your MBA closes it and runs away. If he dosn't close it the protection becomes of course worthless, but thats not so reallistic, just because it a lot easier to run away with a closed laptop.

Please note that I had to use the command "destroyfvkeyonstandby" instead of "destroyfvkeyonhibernate", cause my system doesn't know that command.

This Mode was the only mode where it wasn't achieved to read the password out of the RAM, at least until now. And please notice it's only safe if the "fast user switch option" is disabled. As written here:

http://img.frameloss.org/wp-content/uploads/2011/09/Lion-Memory-Acquisition.pdf

But even if wasn't possible to read the password out of the RAM via FireWire the author admits that it could be possible to read ot out through a Thunderbolt port. This would of course only be possible if the hybernatemode 25 is buggy and doesn't power off the RAM indeed.

The other thing to keep in mind is that the author found the destination were the encryption password and all the user password are saved on the hard drive !!!

--> The are very probably saved encrypted, the question is which encryption is used and which password does the system use to encrypt them???

The MBA doesn't have a FireWire port, and while it might be possible that the Thunderbolt port is vulnerable to this attack too nobody has yet confirmed nor denied this. As far as I know all Thulderbolt-equipped Macs have IOMMU/VT-d and can thus be protected from RAM-reading attacks.

triumph1337 wrote:

wrong. you're completely mistaken about that providing anything but a false sense of security. An attacker could extract the contents of RAM via your thunderbolt port the same way the attack was preformed via firewire at blackhat conference last year.

Really? Do you have positive confirmation, that this is still possible under 10.7.2 ?

You already discribed this problem here:

https://discussions.apple.com/thread/3508926

I also answered you in this thread, that it should not be possible anymore (since 10.7.2), but you didn't reply.

I'm very sorry about "destroyfvkeyonhibernate", it's destroyfvkeyonstandby! I typed this post on Linux, so I couldn't copy the command line. Seems noone else noticed this so far except for FranzFromFrankfurt.

Spacemarine wrote:

triumph1337 wrote:

wrong. you're completely mistaken about that providing anything but a false sense of security. An attacker could extract the contents of RAM via your thunderbolt port the same way the attack was preformed via firewire at blackhat conference last year.

Really? Do you have positive confirmation, that this is still possible under 10.7.2 ?

You already discribed this problem here:

https://discussions.apple.com/thread/3508926

I also answered you in this thread, that it should not be possible anymore (since 10.7.2), but you didn't reply.

yes I have confirmation that a thunderbolt port of libforensic1394 which functions as a drop-in replacement works under 10.7.2. There are at least 10 well known researchers on bugtraq who have this code. Immunity Inc has this code. It leverages the northbridge in a novel way to directly access the memory. From what I undersatnd there were actually multiple ways to accomplish it and there's so much attack surface because the thunderbolt architecture is based on PCI express. The thunderbolt hardware architecture was not designed to be secure in that way.

With firewire the operating system has some control over DMA etc. Apple is doing this with either IOMMU or VT-d extensions within the processor to remap DMA to an isolated VM space when the screensaver is active. Thunderbolt however is able to communicate directly to memory via the northbridge.

All apple did was leverage VT-d to break the oldest most publiclly available tool instead of actually implimenting the crypto system correctly. They are not dummies over at Apple so they must be doing it this way because they don't want to implient it correctly. They are probably being pressured from many directions to not impliment to crypto system correctly and it's our duty to force them to take it seriously. Unfortunately I can't release any proof of concept code to prove this because I don't have access to the code and I don't fully understand tha attack vector, but I have seen it work, and I do know that the cryptosystem is broken as long as the key is not completely flushed.

🙂

if what you say is true, then yes, my setup would be insecure. In this case, this should be made public to force apple to stop selling broken systems to their customers.

Spacemarine wrote:

if what you say is true, then yes, my setup would be insecure. In this case, this should be made public to force apple to stop selling broken systems to their customers.

I agree it *should* be made public but I personally have no control over that. These companies like say Immunity Inc make millions of dollars off of selling weaponized vulnerabiliies to the highest corporate bidder. They have no incentive to release it. The other researchers I spoke of also work for companies who don't want to cross Apple's path in this particular way at this particular time. HOWEVER it seems you've mised my entire point.

The point of what I'm trying to say is that we don't need to see the release of a new exploit tool in order to know that the cryptosystem is broken. The fact the the key is not purged is PROOF that the cryptosystem is broken. If the system were implimented correctly then the thunderbolt port wouldn't even theoretically matter at all. We already have all of the proof we should need to pressure apple into fixing their broken cryptosystem. We know that the key cannot be flushed with the current system, thats all we should need to know.

triumph1337 wrote:

The fact the the key is not purged is PROOF that the cryptosystem is broken.

Why? If there were no thunderbolt port or if the OS would prevent the ram from being read without the consent of the user, would you still make this statement?

Spacemarine wrote:

triumph1337 wrote:

The fact the the key is not purged is PROOF that the cryptosystem is broken.

Why? If there were no thunderbolt port or if the OS would prevent the ram from being read without the consent of the user, would you still make this statement?

Yes I would still make the statement but I wouldn't be making as much of a fuss becuase only extremely well funded adversaries would be able to preform the attack at that point. It could be done by freezing the RAM cryogenically and then retrieving the key.

Cryogenically frozen RAM bypasses all disk encryption methods ...

This attack vector is less of an issue on the MBA because the RAM is on board but it's still vulnerable. However I don't want to digress into the specifics of this obscure freezing attack becuase the reality we face is much worse. Under the current system anybody can preform the attack with a regular old thunderbolt cable. It's not just some obscure software security companies who have the code to preform this attack. Immunity Inc leases it out to whatever corproations can afford it. That means if you're an executive and you keep confidential information on your laptop your competition could hire someone to steal your laptop and then they could lease the thunderbolt attack from Immunity Inc, and then you're owned.

This is not just the rantings of some paranoid who's worried about the FBI getting at his data. Corporate espionage is a reality and the professionals who participate in it have access to Immunity's codebase. As loyal customers of Apple we deserve to not be lied to. In this case I think we are being lied to. They are selling an intentionally crippled security software. No competent security professional would advise Apple to leave the key in RAM or on disk. It's the single most obvious way to break the security of the whole system. Apple must have made the decision to do so against the common sense advice of the professionals.