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

Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

lekkertech.net

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#61

Post by dfranke »

tptacek wrote: post #28
UnoriginalGuy wrote: post #21

Earlier quoted context omitted.

This: > Perhaps Akamai is not actually running this version in production, but another 'super secure' allocator. In either case they should not be sending out non-functional, bug ridden patches to the OpenSSL community, while claiming they protected Akamai against the Heartbleed attack. Andy Ellis, CSO of Akamai, said on Twitter that the 'secure' allocator was written 13 years ago. I'm happy to provide the results of…

This post isn't simply "ridiculing" the proposed allocator design. Did you work on this allocator? If not, can I suggest that you be a little careful? It's one thing to stick up for Akamai's developers; it's another to be thin-skinned on their behalf. It's possible that Akamai's devs, being adults, professionals, and engaged with software security, actually want to hear Willem Pinckaers' take on their allocator.

Speaking as a security researcher at Akamai, I can say that tptacek is 100% correct here. We're absolutely better off for having received Willem's report, and I'm pretty sure we're all mature enough to tolerate the jabs that accompanied it.

I didn't have any part in writing this allocator, but I was asked to do a code review prior to publication. I told Rich Salz that it would take me at least two days to do a thorough one, and we both made the decision that it was better that we just get this code out there for public review and discussion than that we wait until we thought it was perfect.

So, with the caveat that we're still evaluating most of Willem's technical claims (and I'm probably going to be in the office all night doing so), the only sentence in Willem's report that I really take exception to is this one:

  In either case they should not be sending out non-functional,
  bug ridden patches to the OpenSSL community, while claiming
  they protected Akamai against the Heartbleed attack.
This statement is self-refuting. If we hadn't published this patch, we wouldn't be having this discussion, and some of the bugs that Willem and others are finding would have gone unnoticed. I almost certainly would have caught the issue with the CRT intermediates if Willem hadn't done so first, but I doubt I'd have caught everything that has or will be identified through public scrutiny.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#62

Post by yukichan »

brians wrote: post #58
abus wrote: post #48

Earlier quoted context omitted.

It would be better if someone independent set it up.

We're talking about it. The patch is dependent on details of our unreleasable (GPL+OpenSSL+all sorts of other things) server.

uh if it's GPL, don't you have to release it?

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#63

Post by cscott »

brians wrote: post #57
cscott wrote: post #37

It comes down to intent. There are two distinct ways to evaluate Akamai's patch: 1. Did Akamai release the PoC patch to start a discussion about how to protect private keys and share their work as a starting point for changing the code? If so, their efforts here should be considered in that vein and any criticism should be used simply to guide the development of a usable and functional patch. 2. On the other hand, if…

It was released as both: we thought that our old protection against swap protected us against Heartbleed. What a stroke of luck. We did check for key values visible in the heap, and on our implementation, in our lab, didn't find them on any version of our software used since we took OpenSSL 1.0.1. We weren't looking for the CRT values. As one part of our response, we decided to publish the code we thought was keeping…

Decisions were made about certificate revocation based on assumptions about this code and Akamai customers ended up being exposed.

Perhaps third-party security validation of such a critical piece of code should be a prerequisite before asserting that no further countermeasures such as key rotation were necessary. Such an action would demonstrate significant diligence as compared to a public release days after you've told customers there was nothing to worry about.

Additionally, that public release didn't directly encourage security review, the deprecating comments on the post were primarily around portability and design.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#64

Post by rocky_ee »

gus_massa wrote: post #49
rocky_ee wrote: post #6

Earlier quoted context omitted.

Pls elaborate

Tptacek has a software security company, and he is one of the unofficially designated security experts here (with cperciva). He is the #1 in the karma ranking and has even more karma that the site founder (pg)! If he says that “[Willem Pinckaers] knows what he's talking about”, for me it’s very strong reference for Willem Pinckaers. Also, we generally don’t like oneliners here, try writing a longer comment. Definitiv…

Ok, Thank you for the clarification. The irony is I probably should have been a bit more elaborate in the context of my question. I'm fairly new on Hacker News and I probably should read more comments pertaining to other posts to get a better perspective of the etiquette on here. But again, thanks for the clarification and I will commit to bringing proper thought to my comments

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#65

Post by pilif »

yukichan wrote: post #62
brians wrote: post #58

Earlier quoted context omitted.

We're talking about it. The patch is dependent on details of our unreleasable (GPL+OpenSSL+all sorts of other things) server.

uh if it's GPL, don't you have to release it?

Nope. As long as they don't distribute it but only run it in a server, they don't have to. This is what the AGPL is changing.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#66

Post by nolok »

tptacek wrote: post #52
nolok wrote: post #12

Earlier quoted context omitted.

Apparently, he is not competent enough to understand what "this is not our actual code but merely a POC" means.

This would have been a cutting bit of wit indeed, had Akamai not stepped on your moment by confirming Willem's central thesis. Ouch.

If the tone of my message was a bit harsh, it was mostly to reflect his, and thankfully I do not have a life boring enough that this is "my moment".

Still, I stand by my point of view that at the time of writing, akamai's POC was presented neither as an absolute final fix nor as their own production version of it, and judging it as such was misplaced.

That akamai realized the flaws he noted in their patch also applies to the real world code doesn't change that.

I never said the flaws he pointed were not real flaws nor unimportant ones, I merely disliked the ridiculous and unjustified tone he used to to destroy a proposal and used the same against him.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#67

Post by brians »

pilif wrote: post #65
yukichan wrote: post #62

Earlier quoted context omitted.

uh if it's GPL, don't you have to release it?

Nope. As long as they don't distribute it but only run it in a server, they don't have to. This is what the AGPL is changing.

Not here: you can't do much with AGPL+OpenSSL. AGPL requires release under AGPL. OpenSSL requires advertising clause. There is no legal way to distribute software including parts you have only under APGL and parts you have only under OpenSSL license.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#68

Post by awalton »

paulhodge wrote: post #44
cscott wrote: post #37

It comes down to intent. There are two distinct ways to evaluate Akamai's patch: 1. Did Akamai release the PoC patch to start a discussion about how to protect private keys and share their work as a starting point for changing the code? If so, their efforts here should be considered in that vein and any criticism should be used simply to guide the development of a usable and functional patch. 2. On the other hand, if…

Even if their intent was just to start a discussion, they are not being helpful by "submitting" such bogus code. It would be easier for an expert to rewrite this patch from scratch than try to figure out all of their flaws and unfinished sections. In one of the email responses, someone pointed out a problem with their code and they responded, "Oops we posted the wrong version" ( http://article.gmane.org/gmane.comp.en…

> Even if their intent was just to start a discussion, they are not being helpful by "submitting" such bogus code.

All code is bogus code until reviewed. That is absolutely central to understand. Linus's Law only works _if_ people are looking at the code. Implicitly thumbs-upping it doesn't solve problems.

Akamai submitted the code, people reviewed it and found flaws. They're taking action to fix their own code, and the community is coming up with various fixes of their own. That's how Open Source Software Development should work.

While I agree with you that it'd probably be better to rewrite the code with a similar approach, it's also important to note that nobody in the OpenSSL community even considered this approach publicly until Akamai published their code.

Any claims they're being disrespectful of people's time is specious - they said from the beginning that this code needed review and shouldn't be merged. This is just one of those issues that comes out in the wash of code review.

TL;DR: Akamai should be lauded on their intentions but like noted by everyone, the code wasn't good enough. Now, with proper review and rewrites, they will be able to protect their customers into the future, and maybe OpenSSL will become a slightly better product for it too.

Re: Willem Pinckaers on Akamai's flawed OpenSSL allocator patch

#70

Post by iiiears »

tptacek wrote: post #47
rgbrenner wrote: post #24

If this code was running on the Akamai networks for years, why did they have a copy laying around that didn't call mprotect? Given the above problems I wonder how Akamai manages to run this in production. How could you misread a two paragraph email so badly. Here, let me shorten it up for you: This patch is a _variant_ of what we've been using to help protect customer keys for a decade. This should really be consider…

This would be a more compelling rebuttal to Willem's post if Akamai hadn't confirmed his central thesis: https://blogs.akamai.com/2014/04/heartbleed-update-v3.html

They used their patch for some length of time, release it to the community and a few hours later a bug is spotted and fixed. Peer review is a good thing.
Post reply on HN