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

21–30 of 79 posts

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

#21

Post by UnoriginalGuy »

tptacek wrote: post #18
StefanKarpinski wrote: post #3

Earlier quoted context omitted.

The tone of his post is rather unfortunate. Still, he raises good points, even if they are put in an unnecessarily aggressive manner.

I disagree. The post is written bluntly, but it argues with factual assertions, not with emotional appeals. I don't think criticism of its tone is warranted or really all that appropriate.

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 my 15 minute security review, since it is so overdue. (To be fair, I found the issue in minutes, but confirmation took longer.)

Comes across quite passive aggressive indeed. The tone is otherwise fine, except that paragraph which is just one giant jab at Akamai.

I guess it is true what they say: No good deed goes unpunished. I'm sure Akamai has learned their lesson and will keep all future patches private to avoid public criticism and ridicule. But on the positive side at least we all know how smart Willem is, which I'm sure was the real point anyway.

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

#22

Post by delsarto »

tptacek wrote: post #19
delsarto wrote: post #9

A review by a security engineer would have prevented a false sense of security Everyone involved in this, from the people who wrote the heartbeat code, the people who committed the code, the people at Akami who wrote this patch, this poster ... all would describe themselves as security engineers. Is everyone but Willem Pinckars incompetent? I think the one lesson to learn is to treat crypto just like you do cloud pro…

Which of the assertions in the post do you disagree with?

None, it's good work.

But the whole episode, and this post in particular, highlights the issue that enough review is never enough. When is the the code secure? When it is written by someone with a good track record? When it gets reviewed and committed by knowledgeable parties? When it's been running for several years without incident? When it passes coverity? When Willem has time to review it?

When I just think about the embedded ssh keys I've got in my few toy systems; if I discovered ssh was broken (and it's happened; look at the Debian bug) I'd be sinking a lot of time figuring out just how to change the keys everywhere. I should have designed for this from the start; lesson learnt. I bet there's lots of admins out there who wish they had better ways to update certs on a moments notice over the past week...

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

#23

Post by yeukhon »

Even if the PoC patch was perfect and is approved by many of the top security folks out there, would Akamai ever share their perfect custom memory allocator with the upstream community.

edit:

okay, whats' wrong with my statement? If they do have a perfect allocator, wouldn't it be nice to know exactly what they did?

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

#24

Post by rgbrenner »

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 considered more of a proof of 
  concept than something that you want to put directly into 
  production. Let me restate that: do not just take this 
  patch and put it into production without careful review.
So to answer your question: this version was never running in production.. and it the initial patch didn't call mprotect because they stripped it out from their version when creating the POC.

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

#25

Post by [deleted] »

UnoriginalGuy wrote: post #21
tptacek wrote: post #18

Earlier quoted context omitted.

I disagree. The post is written bluntly, but it argues with factual assertions, not with emotional appeals. I don't think criticism of its tone is warranted or really all that appropriate.

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…

[deleted]

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

#27

Post by keithgabryelski »

__alexs wrote: post #4

OpenSSL has pretty good support for HSMs in the form of their ENGINE API. It seems like it would be possible to use this layer to move all key handling and crypto operations out of the process that was dealing with TLS. Process isolation seems like a much better way of getting this kind of security than weird allocator tricks.

gosh, i see this "weird allocator trick" to be exceptionally insightful as to the possible attacks that and likely vulnerabilities that may be introduced into code.

One of the biggest issues for a development team isn't how to do something, but how to do something so that someone (who has taken over the project) won't screw it up in 10 years when you and all your cohorts have left and are island hoping and coconut drink doing.

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

#28

Post by tptacek »

UnoriginalGuy wrote: post #21
tptacek wrote: post #18

Earlier quoted context omitted.

I disagree. The post is written bluntly, but it argues with factual assertions, not with emotional appeals. I don't think criticism of its tone is warranted or really all that appropriate.

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.

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

#29

Post by lobster_johnson »

UnoriginalGuy wrote: post #21
tptacek wrote: post #18

Earlier quoted context omitted.

I disagree. The post is written bluntly, but it argues with factual assertions, not with emotional appeals. I don't think criticism of its tone is warranted or really all that appropriate.

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…

> Comes across quite passive aggressive indeed

Surely it's not passive aggressive when the author not only critiqued the code (an arguably "active" act of initiative), but offers to review the unpublished patch as well.

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

#30

Post by makomk »

delsarto wrote: post #9

A review by a security engineer would have prevented a false sense of security Everyone involved in this, from the people who wrote the heartbeat code, the people who committed the code, the people at Akami who wrote this patch, this poster ... all would describe themselves as security engineers. Is everyone but Willem Pinckars incompetent? I think the one lesson to learn is to treat crypto just like you do cloud pro…

There's been a lot of overly-confident statements about Heartbleed not being a big deal from apparently competent people these last few days. I'm not sure what it is about it that causes security professionals to spout off without testing their assumptions, but...
Post reply on HN