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

51–60 of 79 posts

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

#51

Post by abus »

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.

Here's a patch that prevents any exploit ever occurring in OpenSSL:

    void *custom_malloc() {  };
It's only a POC though so you'll have to adapt it. You can go ahead and begin praising me and flaming my critics.

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

#52

Post by tptacek »

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.

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

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

#53

Post by brians »

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.

Yup. Hard to read! Better that than not to read it.

As Rich Salz said in the post to openssl-dev, this is a prototype that nobody should take and use straight. We did think we were pretty lucky that our old patch to keep keys from being swapped to disk could help us against Heartbleed. A major voice in the internal decision about whether to release it or keep it secret as a "competitive advantage" was the possibility that we were wrong---in the hopes that someone would discover this and tell us if so. We were wrong. Pinckaers discovered this, and told us so.

He can mock my coffee as weak and my nose as big for all I care, in return for that necessary warning that we were mistaken.

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

#54

Post by brians »

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.

We're still evaluating some of his arguments. I still believe some of them are true in the general case, but do not apply to our specific embedding of this code. I say that aware that I was mistaken 12 hours ago, and so very well could be mistaken now.

But I am reasonably convinced that the CRT values are loaded into the normal heap, where they're available to a normal Heartbleed attack. Pinckaers doesn't have to be right about all his points to be right---just once---and I'm pretty sure he's right at least that once.

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

#55

Post by brians »

hueving wrote: post #17
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.

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.

Yes. Our actual implementation was vulnerable. We disabled TLS heartbeat before 5 April 2014, so are not still vulnerable.

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

#56

Post by tptacek »

brians wrote: post #53
tptacek wrote: post #28

Earlier quoted context omitted.

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.

Yup. Hard to read! Better that than not to read it. As Rich Salz said in the post to openssl-dev, this is a prototype that nobody should take and use straight. We did think we were pretty lucky that our old patch to keep keys from being swapped to disk could help us against Heartbleed. A major voice in the internal decision about whether to release it or keep it secret as a "competitive advantage" was the possibility…

You probably meant something subtly different than what "competitive advantage" sounds like, w/r/t hardening the public OpenSSL code. :)

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

#57

Post by brians »

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 us safe. If we were right, sure, there's good PR from that. If we were wrong, it's a chance to find out and get right. Less wrong, anyway.

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

#58

Post by brians »

abus wrote: post #48
yukichan wrote: post #5

I'd like to see Akamai create a CloudFlare style challenge using their patch and a compromised version of OpenSSL and see if anyone can get the private keys from it.

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.

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

#59

Post by brians »

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…

I hope Akamai has learned our lesson: upstream earlier, among others.

Watch and see.

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

#60

Post by Pacabel »

babs474 wrote: post #40
tptacek wrote: post #28

Earlier quoted context omitted.

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.

tptacek, we all want to hear Willem Pinckaers' take, it is really good stuff. I also want to hear ideas from Akamai, even if they aren't perfect. Perhaps they can lead to good things. Unfortunately Pinckaers' commentary is a little bit too hostile and calls for Akamai to cease sharing ideas[1]. I'm sure Akamai's developers are "adult" enough, as you say, to handle it. However there is a trope in software development…

I think there's a difference between sharing ideas and sharing code.

An idea or concept on its own can't really do much, at least until it's put into practice somehow. The potential for harm is quite minimal, if it even exists.

Code, on the other hand, can often be directly used with relative ease by people who may not fully understand the possible implications of using such code. The potential for harm exists, and could be significant.

In the context of security, it's important to avoid potentially-harmful code wherever possible. If somebody has concerns about some code, regardless of who wrote it, it is best to express those concerns in a very blunt and direct manner.

Security is just not something to fool around with. The hard questions and painful facts should be out in the open, especially when code is involved and capable of being used. It's just not the time or place for pussyfooting around.

Post reply on HN