MacBook Pro Not Waking from Hibernation

The Problem

Some time ago I upgraded my memory from the standard (4G I think) to 16G, via Crucial. Crucial is awesome and I highly recommend them. While I haven't had any memory issues whatsoever, and running 16G is just hot, I've had issues when my lappy has resumed from hibernation.

Lion (and older OS X versions) supports what they call SafeSleep. While SafeSleep is probably not needed on Lion since it has the fancy Resume features in the applications, by default on portables, it's enabled. The pmset manual page makes this statement:

hibernatemode = 3 (binary 0011) by default on supported portables. 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.

In more detail:

0000 0001 (bit 0) enables hibernation; causes OS X to write memory state to hibernation image at sleep time. On wake (without bit 1 set) OS X will resume from the hibernation image. Bit 0 set (without bit 1 set) causes OS X to write memory state and immediately hibernate at sleep time.

0000 0010 (bit 1), in conjunction with bit 0, causes OS X to maintain system state in memory and leave system power on until battery level drops below a near empty threshold (This enables quicker wakeup from memory while battery power is available). Upon nearly emptying the battery, OS X shuts off all system power and hibernates; on wake the system will resume from hibernation image, not from memory.

Last night I forgot to plug in my lappy. Now, my lappy usually doesn't go into hibernation often. In fact, I think this was the second time it has since I got it. And just like the first time, it didn't restore itself properly. During what I assume was the EFI boot sequence, about 1/2 way during  restore, the system started beeping. Like, in that "Oh fuck something's wrong" way. Assuming that the file system was probably not in a happy state either, this could definitely lead to bad mojo down the road. So, how to fix?

Well, gotta figure out the problem first, right?

The Test

My first idea was that the 16G memory, which isn't technically supported by Apple, was causing a hiccup somewhere. Since the problem seemed in restore, I figured if I could perform a restore with the original memory, and then the 16G, that would reasonably rule out just having an unsupported memory size. Here's the test I went with:

• Original Memory Test:
• Fully shutdown, including a power down.
• Swap out 16G with original memory.
• Power back up.
• Force hibernation / SafeSleep.
• Restore from hibernation. Does this work? Maybe hibernation is just broken with FileVault and my setup...
• 16G Memory Test:
• If the above works, then power down again.
• Swap out original with 16G.
• Repeat everything else above.

As I started doing this, I realized there's no obvious way to force a hibernation with OS X Lion. There seemed to be some third-party utilities that do this. But, c'mon, why the heck should I download a utility that forces a hibernation?

Reading more of the pmset manual page, I came across the standby options:

standby causes kernel power management to automatically hibernate a machine after it has slept for a specified time period. This saves power while asleep. This setting defaults to ON for supported hardware. The setting standby will be visible in pmset -g if the feature is supported on this machine.

standby only works if hibernation is turned on to hibernatemode 3 or 25.

standbydelay specifies the delay, in seconds, before writing the hibernation image to disk and powering off memory for Standby.

My hack-around was to enable standby, which was disabled by default, set the standbydelay to a low value (30), and then put the laptop to sleep. My lappy's configured to sleep when only on battery power, so I just disconnected it and put it to sleep via the Sleep option in the drop down Apple menu. This was done via the following command:
sudo pmset -b standby 1 standbydelay 30

I performed the test above first with original memory and then with the 16G. In both cases, the laptop was able to resume without a problem and without beeping. Sweet! The 16G in and of itself wasn't an issue. Hmm, what was?

The Guess

Re-reading the pmset manual and the hibernation options, the following popped out (emphasis added):

0000 0010 (bit 1), in conjunction with bit 0, causes OS X to maintain system state in memory and leave system power on until battery level drops below a near empty threshold (This enables quicker wakeup from memory while battery power is available). Upon nearly emptying the battery, OS X shuts off all system power and hibernates; on wake the system will resume from hibernation image, not from memory.

OK, so here's the guess. I'm running of an HDD versus an SSD. Having 16G of data written to disk takes longer that what the original memory is at. My guess is this threshold value is set to a low time remaining value, say 10 minutes estimated remaining. Since the 16G is a larger value than expected, it might not actually be fully written to disk when the battery has drained. And since it's writing more to disk, it's using more battery power, depleting it sooner than expected.

The Love

While I was reading the pmset manual, I came across this tidbit:

destroyfvkeyonstandby - Destroy File Vault Key when going to standbymode. 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)

@diretraversal pointed me to a link on someone using the Thunderbolt slot to access memory again (similar to the Firewire attack of old). Now, since I am using sleep → standby → hibernate and also using FileVault, I could take advantage of this option as a best effort defense against someone attacking my memory and recovering my FileVault key. This option was enabled via the following command:
sudo pmset -b destroyfvkeyonstandby 1
While I already had "Require password immediately after sleep or screen saver begins", there wasn't a guarantee that the key was actually cleared; I just was asked for the password again. Now it seems like it is, although it's just a setting. Who knows what's going on under the hood :)

The Recap

• Lappy wasn't restoring correctly from hibernation.
• In all likelihood, this was because OS X didn't write to disk early enough.
• The lappy goes into sleep after 15 idle minutes pass whilst unplugged or the lid closed.
• It now goes into standby mode 30 seconds after that, which forces a hibernation mode and memory power down.
• And as a check, the FileVault key is (hopefully) wiped from existence whenever standby occurs.

The suck of all of this is that I'll have longer restore times every time I resume. 16G of data needs to be pushed back into the memory, from an HDD. It's not a horrible wait, just a bit extra. But at least I won't have the risk of a corrupted file system from an incomplete write. And of course Murphy would predict this occurring when I'm not near my backups :)

Update 1: nice link to someone actually doing an attack against FileVault2 in Lion.

The Losing of a Consciousness

I sit here, high above my Brooklyn city below. My view is west, blotted by Brooklyn Heights, down to Buttermilk Channel, up to the East River, across to New Jersey. My view is distance and beautiful. It is away. My view is a perfect analogy of my consciousness. Distance, away. Ignorant. Call this the sub-ego, a portion of the self whose aim to to protect the self by ignorance.

I once recalled the difficulty of asking a friend to lend me $20. I felt a heavy obligation to pay it back. It took a week, where I saved a bit each day. The stress of this was an emotional stir. At this time in my life, that $20 was a large amount to me. It supported me. It was nourishment. Today, $20 has the same meaning to me as $100. They are peers in my mind. This is not me being a braggart. Perhaps, it is more of a confession of how far away I have gotten from my roots.

The sub-ego, or whatever it should be called, drove me to seek out what I did not have or did not want. I didn't dislike being poor, because it was what I knew. And no one could have considered me a pauper, for I wasn't destitute. But as I reaped the fruits of my experience, fertilized by the many in my society, I became ignorant of who I was. I forgot the meaning of $20.

It's amazing what this apathy, grown from ignorance, does to the self. From my view, I can see the tops of buildings, the iconic precipices jutting out of the jungle of Manhattan. Yet, I cannot see the trees below. Nor can I see the courage of those willing to camp out in these trees, waving their fists against what they deem is wrong with society. I cannot hear them, for indifference deafens the ears. I cannot feel them, because I am comfortably numb.

Time Sharing My Time

So I'm trying something out today, on this wonderful Labor Day. I find I start a lot of small to medium projects that get going, but then die. I could create a list, though it would just make me sad. I find I keep on going on a project when I keep on accumulating small *wins*. That could be added functionality to a program, seeing the accomplishment in action, or getting positive feedback from others. Yes, my ego needs a lot of care and uptake and my mind loves the dopamine release on receiving a reward. Whatever, gotta work with the machine I got :-)

So, today, I tried time sharing my projects. I started a 45 minute timer, and walked down a list of projects. Each got 45 minutes, then whatever amount of break in between. It's a holiday so the breaks are a reward into themselves. If I was billing or charging to a company project, I'd probably care more (or not ; -)

Well, it seemed to work out so far. I went from assessing some technology, documenting changes (locally) to attack surface wording for an OWASP project, playing with puppet, and now onto some node.js stuff. That variability helps keep me motivated to do more, snack bites at a time. Even if I got steam, I was happy to start. It was kinda like a cliffhanger. Otherwise, I run the risk of going through a manic-obsessive cycle, where I spend 10 hrs doing one task and then don't touch it for a month.

Time will tell if this little process change helps or hinders. But at least on today's holiday, it helps.

Cheers!

Measuring An Application's Attack Surface To Measure Consultancies

The ability to as-automatically-as-possible measure an application's surface area / attack surface should be one of the Millennium Prizes. Sadly, they only care about stupid problems such as does P=NP? Of course it does! For application security, this measurement can provide a comparable metric to the application's potential for security issues. Enough on that. I'm not trying to prove out an app's security this time. I want navel-gaze at our wonderful infosec industry.

An interesting byproduct of adequately measuring an app's attack surface, and to use the CMU researchers' verbiage, channels, methods, data and entry points, is that it provides a lot of scoping information on the application. No, no, no, I don't care about using this to guess the right amount of hours to assess an app (although that's possible). Rather, imagine if the client stated to a consultancy the following.

Client: "Hello Consultancy."
Consultancy: "Hello Client."
Client: "We have App XZY that has one channel of concern, with 15 direct entry points (methods that receive environment data)."
Consultancy: "Sounds good!"

[... time passes, consultancy is assessing application ...]
Consultancy: "Hello again Client!"
Client: "Hello again Consultancy!"
Consultancy: "We analyzed each of the 15 entry points and found the following. On average, each entry point used 25 different portions of the data, for a total of 375 data fragments [my word] consumed by the entry points. Out of these 375 data fragments, 200 were used in a conditional statement somehow, 100 were persisted by the application and 75 were reflected back to the user. We then examined each of those data fragments for appropriate validation and contextual encoding, if necessary. Blah blah blah XSS blah blah blah SQLi blah blah blah."
Client: "Wow! That's a lot of numbers that don't mean anything to me!!!"
Consultancy: "Oh, hold the boat there Mr. Client! You can start to use these numbers to measure the efficacy of other consultancies and tools. Of course that new Sprint you're about to do on your codebase will screw up all of these numbers. But, you can pay me to measure this again!"
Client: "Oh, I see. So, I can measure your work against another consultancy's work and see how closely you all got."
Consultancy: "Yeppers. So, when we leave here, you'll have at least an idea of what we did. You should then get someone else in the door to do an assessment on this app and see what they come up with. The sooner, the better, since you're pushing new code to QA this Friday."


So, yeah, measuring an app's attack surface down to how many data fragments exist (think HTTP parameters or header content for a web app) and how they're used can become a relative metric on the efficacy of consultancies, in addition to the many other benefits it provides. But, as I snarkily allude to above, it's fraught with issues, especially on the "freshness" of those measurements. I so wish magical tools did this. Our industry, and our client's appsec, would only benefit from it.

RSA SecurID Hack, Should I Care?

Twitter was abuzz yesterday and today on the RSA hack. From what I could infer, worst case, the SecurID seed files may have been disclosed in a hack. A quick primer on SecurID is needed to see why this is and isn't an issue.

Token: hardware or software device that displays a token code
Token code: pseudo-random numbers displayed on a RSA token. Can change at different frequencies (30 seconds, 1 minute, etc.)
PIN: user's secret code. Can be numeric or alphanumeric, depending upon configuration.
Passcode: PIN+tokencode

RSA SecurID uses soft and hard tokens. I'll focus on the hard tokens for this. The tokens as I understand them are PRNG. Each token has a random seed to start its PRNG. The date and time the token was started with the seed, along with the seed itself, and the token's serial number, are sent to the customer. The customer then loads this seed file into the Primary SecurID server at the customer's premise. The Primary then can guess the current tokencode displayed on the token by inputting this seed into the PRNG. Clock-skew aside, the code computed by the Primary should be the code displayed on the token.

As the customer adds users to the system, the customer associates a token to some user ID. This association should never be known outside of the Primary, secondaries, and backups. Usually front-end authenticators communicate to the Primary, via RADIUS, RSA's own proprietary protocol, or other supported methods. So, assuming an attacker has obtained the seed files, token serial numbers, and the organization that received the seed files, they'll still need to know the user ID association, the user's PIN, and the relative clock skew of the token.

The RSA hack though only buys the attacker the first part of the equation (seed, token, date). The attacker would still need to perform a targeted attack against a user / org to obtain the token <=> user mapping AND the user's PIN. The Primary has mitigating controls to lock out a user after some amount of failed login attempts. But, let's hand-wave and say the attacker has somehow obtained the token <=> user account mapping and the user's PIN, which could be the user's domain password in some setups. They still need to generate the tokencode on the token.

Getting back to clock skew, since physical tokens are physical, its clock will skew over time. The Primary stores this skew and allows a range. The more the token is used, the better the Primary will know its skew. If the token is too far out of skew, the Primary will log an event and require the to user enter the subsequent token code. If the token continues go to out of skew, the Primary will disallow its use and require the user to obtain a new token. An attacker starting a blind attack will not know the token's relative skew. So, even if this is a targeted attack against an individual, where the attacker knows the seed, token serial number, user ID, and user's PIN, there's still even a chance that the attacker will not be able to authenticate because of the token's clock skew will be too far off.

With all of this, there is some worry. If you're in a small organization with say 20 people, it'll be easier for a knowledgeable attacker to associate some random token to some user account. RSA should also do the right thing and allow organizations to replace their tokens if the organizations deem it necessary, free of charge. A large organization will probably not do this, though. It's costly to do mass upgrades of tokens. For example, each token has an expiration date of usually 2-3 years. After this time, an organization will have to phase in a token replacement process. Support calls go up. People get locked out. It's a pain. But, if you're a small shop, it's easier to manage this. And, if you're a small shop, you're at a higher risk.

In the end, it's about your organization's relative risk. I just don't see a big story here.

(Updated 11:37 EDT: noticed I wrote PIN/passcode before. This was incorrect. Changed to PIN.)

Dropping the Race Card

I recently watched again the movie Malcolm X. There's a good scene when Malcolm X and Baines are going through an English dictionary and comparing connotations between words starting or containing white versus black. The movie posits English words containing white often have some type of positive connotation whilst words containing black have negative connotations. Does infosec and IT in general carry over these connotations? To me...

• Black-box versus white-box testing: white-box is more open, transparent, easier to test
• Blacklists versus white lists: blacklists are bad, mmmkay
• Black hats versus white hats: I'm apathetic to either but those evil blackhat scofflaws! ;-)
• ...

Yeah, it seems to me. This isn't a poke at Infosec by me since I haven't perceived overt racism by the people I follow or with whom I associate. And also to be fair, these words weren't introduced by Infosec. They were borrowed from some other context.

However, being ethnically a Euro-mutt, my perceptions are more than likely biased. Words do carry meaning, implied or not. I don't see this as a political-correctness issue. Rather, our words frame our mindset. Kinda like a same-origin policy breach. If I connote a feeling with a particular word, it will by nature, leak out into different realms of my being.

Now, having grown up and lived in Minnesota (you betcha!) most of my life, I do not connote the word white with 100% positive emotions; white snow definitely solicits negative feelings in me :-) But I do see the connotations and don't want to perpetuate them. Sadly, the alternatives aren't full of awesome-sauce:

• Black hat versus white hat: unauthorized hackers versus authorized hackers? (and hackers carries its own connotations... geez)
• Blacklists versus white-lists: exclusion-only filters versus inclusion-only filters? (7 syllables to replace 2 ain't cool)
• Black-box testing versus white-box testing: zero-knowledge testing versus full-knowledge testing? (not too bad)

So, as I lose the connotations I gain verbosity. Foo. Win some, lose some. At least I'll connote dry, boring words than some deep-seated emotion. I guess that's a win, ain't it?

Complexity != Insecurity

Why do organizations often tend to introduce more complexity! Complexity is harmful for security ("KISS" principle) - @xme

I saw this tweet this morning and cried again. It was a really long cry. Actually, it was sweat going into my eyes because I'm out of shape and on the elliptical. Pretend they were tears of sadness!

Complexity does not equal insecurity. Complexity is not harmful for security. Heck, complexity is welcomed! Sometimes... And, arguably, sometimes not. Complexity can be needed for security, scalability, and consistency. And brother, I'm gonna preach on why.

Complexity Needed For Security

This is a cheap shot. Tell me, what's more of a complex protocol? HTTP or HTTP over a TLS connection? Think TLS isn't complex? It is. But its complexity and functionality add confidentiality, integrity, and authentication to a connection that doesn't directly offer those features. I won't focus on this one, but think about it.

Complexity Needed for Scalability

Before venturing here, be familiar with Big O notation. At least don't be afraid of O(1), O(N), and O(c^N).

UNIX systems manage passwords via a shadow or master password file. A sysadmin managing a small number of UNIX systems may be inclined to manually make updates to these files via their supported methods. The sysadmin might have to infrequently add or delete accounts, as needed and requested. This is very manageable and scales well to the scenario.

The sysadmin didn't realize his company would explode in growth over the next year. Each week brought on scores and scores of new employees and also the need for more and more servers. Now, instead of managing a couple changes a day over a couple systems, the sysadmin is coping with numerous changes a day, across a growing expanse of systems. Performing this manually is time consuming and also adds inflexibility if the sysadmin needs to quickly disable access.

The sysadmin, being lazy, hooks up to the company's Active Directory instance via LDAP. Now, the sysadmin needs to modify PAM modules (authentication) and name service lookups (authorization) across all of these systems. The sysadmin has effectively increased the complexity of a login from a local lookup to a remote lookup because a procedure that was O(N*M) for a small number of users (N) and a small number of servers (M) is inappropriate for larger sizes of N and M. And the sysadmin gets a security benefit by being able to quickly lock out or disable an account if needed. Is this added complexity more or less insecure?

Complexity Needed for Consistency

Building upon the LDAP example, the sysadmin was managing just CentOS servers. After the growth, the servers were made up of Solaris, CentOS, Redhat and FreeBSD because of business needs. Each of these had different ways to enforce account capabilities and restrictions, such as number of failed attempts before lock out, password complexity and strength, and password expiry days.

Some systems couldn't support what the policy required. Others took time to understand, test, and implement. And others would only work for certain services, say OpenSSH, but not other services, on the server. By having PAM support the authentication and connecting to the LDAP server, the LDAP server can be a single point of control. Or, rather in Big O notation, the sysadmin reduced an O(N) problem to an O(1) problem, with N being the number of servers needing the change. Oh, and I won't mention that the sysadmin will add some more complexity by using STARTTLS with his LDAP implementation to not disclose the hashes being sent across the wire ;-)

Trite Examples, Blah!

Perhaps. The point I'm trying to make is that complexity isn't and shouldn't be viewed as a bastard in the eyes of security. It's not. If the goal of complexity is commensurate with security goals, then it's a win. If complexity changes a process from O(N) to O(1), awesome! If complexity actually adds security at little perceived loss, even better. So, please, if you're gonna beat up on complexity, at least say unnecessary complexity. Because there's a lot of complexity out there that's keeping us secure, and it's a good thing :-)