Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heartbleed Update v3

blogs.akamai.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Heartbleed Update v3

#21

Post by Danieru »

mynameisvlad wrote: post #17
beambot wrote: post #15

Willem's letter to Akamai addressed three areas where their patch was likely insufficient: (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. (…

Why would their update need to address more than just (1)? That's the only part of the problem that they have to deal with. The OpenSSL team should be the one answering (2) and (3), since it's OpenSSL that copies the PK/parts after it's been read, or allocate temp vars for intermediates. If Akamai chooses to patch those two problems and then releases it to open source like their initial patch, then they can answer th…

(2) & (3) are not bugs for OpenSSL because only Akamai is trying to segregate the key data.

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.

Re: Heartbleed Update v3

#22

Post by csoandy »

beambot wrote: post #15

Willem's letter to Akamai addressed three areas where their patch was likely insufficient: (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. (…

We are, in fact, evaluating those other claims, and testing them in our labs. We are also evaluating claims made by other researchers, both publicly and privately; and we hope to end up with both a better library out of this, as well as a better understanding of the hazards we do and don't provide safeties against.

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.

Re: Heartbleed Update v3

#24

Post by daeken »

[deleted] wrote: post #23

[deleted]

When a company says "we're not changing our potentially compromised keys because we're protected by this magic box" and you punch a million holes in the magic box, your goal should be to make it well known that the protection is faulty. He accomplished that quickly, and now they're finally doing the right thing.

Re: Heartbleed Update v3

#25

Post by jbg_ »

Sami_Lehtinen wrote: post #20

Why people are only talking about SSL keys? Because Heartbleed allowed to fetch any data, that could have also included SSH keys and or any other authentication credentials / information the server got, for itself or to other services. As example if your site got Facebook API keys it's possible that those have been leaking too.

Unless your web server makes SSH connections from some kind of in-process application, why would this bug allow SSH keys to leak?

Re: Heartbleed Update v3

#26

Post by forrestthewoods »

This does not inspire confidence in akamai for me. These days people on the internet seem to get super excited when various companies write post mortems on how they screwed up. Yay, they screwed up and were honest about it!!! I find those to be wildly overrated. I'd rather there no be a screw-up to begin with. And I don't particularly care if you come clean or not.

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.

Re: Heartbleed Update v3

#27

Post by blahedo »

daeken wrote: post #18
hrrsn wrote: post #5

Good response from Akamai. No beating around the bush there.

No, this was not a good response. It was well written and took responsibility for bad code, but it failed to address the elephant in the room: why were keys not immediately rotated? 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…

No, that goes too far the other way. If I have legitimate reason to believe that an exploit does not affect me (especially if it's because I acknowledged its possibility and programmed defensively against it), why would I automatically act as if I were breached too?

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.)

Re: Heartbleed Update v3

#28

Post by orblivion »

sobkas wrote: post #12
glimcat wrote: post #6

Earlier quoted context omitted.

Also: the way this played out makes an awesome story for the next time Akamai experiences internal pushback against participating in open source. "Remember that one time it saved our bacon" is a political goldmine.

They are only in problem now, because they have released the patch. If no one outside the company saw that patch, they could spot the problem and fix it without anyone noticing and creating a PR disaster. They probably wouldn't, but they could. That is one argument someone could use against "participating in open source". It's a bit to late for saving bacon, patch should be publicly reviewed before it went into produ…

I just want to say I don't think you deserve to get voted down (as you currently have been). I was thinking the same thing about this story - it's very interesting because it highlights the (utilitarian) philosophical battle around Open Source. It's really not totally clear in which case they were safer. Your position should at least be considered.

Re: Heartbleed Update v3

#29

Post by Narkov »

daeken wrote: post #18
hrrsn wrote: post #5

Good response from Akamai. No beating around the bush there.

No, this was not a good response. It was well written and took responsibility for bad code, but it failed to address the elephant in the room: why were keys not immediately rotated? 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…

They believed that they were covered and that no compromise could/did occur. It's a mistake they now acknowledge but they have owned up to it and are taking action - just as you suggest.

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.

Re: Heartbleed Update v3

#30

Post by [deleted] »

daeken wrote: post #24
[deleted] wrote: post #23

[deleted]

When a company says "we're not changing our potentially compromised keys because we're protected by this magic box" and you punch a million holes in the magic box, your goal should be to make it well known that the protection is faulty. He accomplished that quickly, and now they're finally doing the right thing.

[deleted]
Post reply on HN