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

11–20 of 79 posts

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

#11

Post by nolok »

ironghost wrote: post #7

The funny thing is the fact that everybody is ignoring that the patch wasn't a patch. It was a POC (read demonstration) with the notes: '...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. It slides into the ASN1 code rather than adding a new API (OPENSS…

Oh but if you do that how are you going to make a pretentious critic to shoot it down ? The akamai guy straight up said "that's not actually our code, and that should not and cannot be used as-is, this is a POC", rendering this entire "answer" irrelevant especially given its mocking tone.

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

#12

Post by nolok »

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…

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

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

#13

Post by kalkin »

fancy_betta wrote: post #8

I'm guessing the patch was broken because they didn't have an actual patch laying around, they had to do a diff against the upstream and try to pick out the relevant parts. That doesn't excuse some of the other errors though, like integer overflows and not checking return codes. That also doesn't excuse the fact that they didn't actually try the patch before sending it out. There could be other pieces that we're miss…

Yes. It's not really fair of the OP to say "this is broken in totally obvious ways and would clearly not actually run" and yet critique it as if it was production code. It's fairly obviously (at this point) a hand-constructed pseudo-diff.

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

#14

Post by yukichan »

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…

I don't think I've worked anywhere where there was a simple way to switch cloud providers with the push of a button. Even migrating to different locations within a cloud provider isn't trivial. You'd have to invest a lot of engineering time from the beginning to get this kind of capability, and you may never realize any value for all the pain.

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

#15

Post by delsarto »

yukichan wrote: post #14
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…

I don't think I've worked anywhere where there was a simple way to switch cloud providers with the push of a button. Even migrating to different locations within a cloud provider isn't trivial. You'd have to invest a lot of engineering time from the beginning to get this kind of capability, and you may never realize any value for all the pain.

Yep; not easy at all ... if it were easy everyone would do it :) I think with tools like puppet and orchestration tools like heat, etc it is getting closer to being easier.

I did got to a Netflix talk once where they said that while moving from AWS would huge, they had a plan and I think from memory they said it would take about a week.

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

#16

Post by davidmat »

StefanKarpinski wrote: post #3
tptacek wrote: post #2

(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)

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

I don't find it aggressive, it seems more like Dutch directness to me. As an inhabitant of a neighbouring country, I must say it's an acquired taste ;)

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

#17

Post by hueving »

nolok wrote: post #12
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…

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

It's not exactly a proof of concept if it doesn't protect the keys, is it?

It strongly hints that even if this is 'only a POC' that their actual implementation is still vulnerable since their POC failed to protect against the very attack is was written to protect against.

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

#18

Post by tptacek »

StefanKarpinski wrote: post #3
tptacek wrote: post #2

(I worked with Willem at Matasano for a couple years, and he knows what he's talking about.)

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.

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

#19

Post by tptacek »

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?

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

#20

Post by hueving »

ironghost wrote: post #7

The funny thing is the fact that everybody is ignoring that the patch wasn't a patch. It was a POC (read demonstration) with the notes: '...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. It slides into the ASN1 code rather than adding a new API (OPENSS…

Isn't a POC supposed to prove a concept? i.e. shouldn't a POC defend against the attack it is stated to defend against?
Post reply on HN