Heartbleed Update v3
blogs.akamai.com
blogs.akamai.com
It's a bit to late for saving bacon, patch should be publicly reviewed before it went into production. So no bacon saved, but there is a hope for a smoke detector.
(1) First question is then, are 'p', 'q' and 'd' the only sensitive parameters? NO. (The Chinese Remainder Theorem parameters are included in OpenSSL private keys by default and they are enough to recover the private key).
(2) Second question: Does OpenSSL ever copy the private key, or parts, after the key has been read? YES.
(3) Third question: Does OpenSSL allocate temporary variables for intermediates when performing operations with a private key. Can they be used to recover the private key? YES and YES.
(Willem's post submitted to HN: https://news.ycombinator.com/item?id=7582990 )
This update from Akamai only addresses (1), AFAICT.
In upstream OpenSSL the intermediates are stored in the same memory pool as the key data. Thus the intermediates do not expose privileged data anywhere it is not already present.
Without addressing issues 2 & 3 Akamai's patch is not a line of defense. It does not guard against dirty memory exploits like Heartbleed, it only increases the difficulty of exploitation.
> In parallel, we are evaluating the other claims made by the researcher, to understand what actions we can take to improve our customer protection.
which seems to imply that they're at least looking into the other questions.
Validating his first claim was sufficient to undermine our belief in key safety; the others are therefore only relevant for protection against future attacks. In that light, it was important to advise our customers and the community at large.
https://www.youtube.com/watch?v=IuSnY_O8DqQ
It is only part of the video, but they talk about searching Google and finding partial private keys, e.g. ---- BEGIN PRIVATE KEY ---.
Even with text missing, it is trivial to recover the entire key, because of redundancy that Akamai neglected to take into account. I never really thought about how those ASCII strings are encoded, but it's actually the 6 or so values encoded. If some are missing, you can recover the others.
In retrospect, why shouldn't the private keyh have RFC 822-like key value format so this is obvious? I don't see why it has to be encoded at all; the format is unnecessarily obscure.
The rest of this talk is also great. Most of it is accessible to non-cryptographers (like me), as long as you understand basic arithmetic and have an undergrad-level overview of public key crypto (which they give). They provide very readable and runnable Sage scripts.
I really like the batch GCD attacks. Very elegant and effective.
Of course we're still waiting. I don't know who's decision it was to not reissue all certs on day 1, but this is an epically bad decision bordering on gross negligence.
Heads should roll.
I've said this a number of times lately, but it bears repeating that the golden rule of security is: If a compromise occurs, assume that everything is compromised. Even if their approach was tested to be perfect, they shouldn't have made the assumption that that actually reflected reality.
They were extraordinarily irresponsible. There's simply no other way to slice it.
Your argument is totally correct if I am simply unsure---if I don't know whether an exploit affects me but I suspect it might, I assume the worst and act accordingly. But in this case Akamai had good reason to believe they were unaffected. (And, when someone demonstrated otherwise, they responded responsibly.)
If you have a memory read out of a process that contains sensitive data, you should always assume that the sensitive data was breached, even if you "programmed defensively against it". Period. No exceptions.
They had good reason to believe they were unaffected, which is why they shouldn't have hit the "oh shit, the world is ending" button. But the decision to not roll their keys in the face of a breach was a massively irresponsible one. We have how many years of major bugs to look at? And in how many cases are the likes of Akamai (that is, organizations with theoretical mitigations in place) actually safe when they think they are?
Always, always assume your protections are faulty in a way that a motivated attacker will figure out.
Your argument hinges on the word "legitimate." I don't do security, but "it looks good to me" is not a legitimate reason to believe that the exploit does not affect you (for any value of "me"). OTOH "I've never used the versions of OpenSSL that have this bug" is a legitimate reason to believe that you're not affected, e.g. Tarsnap's explanation [1]. I'd also recommend that post for another take on what defensive programming looks like in this context.
[1] http://www.daemonology.net/blog/2014-04-09-tarsnap-no-heartb...
I believe their actions are honest and completely reasonable. If they had known they still had an issue I seriously doubt they would have publicised the patch and risk the issue they now have.
I completely agree that their actions are honest, and I seriously doubt they would have played things this way if they knew their protections were faulty. I'm not saying that they're acting maliciously; I'm saying that they acted in an arrogant and irresponsible way.
If an attacker can read memory out of a process containing sensitive data, the assumption should always be that they got the keys to the kingdom even if they didn't. I'm not saying they didn't do their best to defend their service -- on the contrary, I think that their defense is a good one -- but that they played chicken with an exploit and ended up on the wrong side of it.
Their customers deserved better.
We both agree on this.
> but that they played chicken with an exploit and ended up on the wrong side of it.
I disagree with this. They thought they had a valid technical solution and did the honourable thing by releasing it. Unfortunately they were wrong but that's a bug and not a arrogance issue.
Actually contributing the code you write is helps _everyone_.
I know bugs are written and bugs happen. It's an unfortunate fact of life. And anyone who posts their code will likely have holes poked in it by the community. But the akamai thing really sets of warning flags. The fact they thought it would work and it doesn't, at all, does not sit right.