Live data from Hacker News

The Heartbleed Challenge

cloudflarechallenge.com

41–50 of 125 posts

Re: The Heartbleed Challenge

#41

You can read more about the CloudFlare Challenge and our own tests on obtaining SSL Private Key material here: http://blog.cloudflare.com/answering-the-critical-question-c... Matthew Prince Co-founder & CEO, CloudFlare

Thanks. This makes a lot of sense, and matches what I saw myself. I never got anything out of nginx, but I found apache quite easy. I never built more than a POC, and left it at that.

I didn't think about it at the time, but it was only on a newly started apache instance.

Coupled with the fact the apache as a frontend tls server is pretty rare on big sites nowadays, I'm feeling pretty good about what did happen, vs what could have happened.

Re: The Heartbleed Challenge

#42

Earlier quoted context omitted.

The bug was discovered by whitehat researchers approximately 12 days ago. It was publicly announced 5 days ago. We got early word of it from the researchers who initially discovered it, allowing us to patch our systems and ensure all sites behind CloudFlare were not vulnerable. However, we have no way of knowing how long blackhats may have had it. It had been present in the OpenSSL software for the last 2+ years. The…

I'm disgusted they chose to share it with you early and not the major Linux distros...

I have not seen any comment by the security researchers about why they choose to disclose to some organizations (such as cloud flare) earlier than the general public or the distributions. Perhaps, they felt the need to have some organizations with very large OpenSSL installations test the patch prior to make sure it worked and did not cause any unexpected problems?

Re: The Heartbleed Challenge

#43

You can read more about the CloudFlare Challenge and our own tests on obtaining SSL Private Key material here: http://blog.cloudflare.com/answering-the-critical-question-c... Matthew Prince Co-founder & CEO, CloudFlare

It seems like a "feature" that you'd want your process to store the private key material as low as possible in the address space so that arbitrary read overruns don't run the risk of hitting it. It seems to just accidentally be this way in nginx, but I wonder if it should just be another (tiny) layer in the overall security design.

Re: The Heartbleed Challenge

#45
I seriously don't expect anyone will find anything (reasons mentioned in the blog post), but that doesn't mean I haven't pointed my exploit that searches for private key material in the return buffer at it on a one second interval. If anything I suppose CloudFlare will be able to produce some pretty pictures of the amount of incoming heartbeats they received!

Re: The Heartbleed Challenge

#46

Earlier quoted context omitted.

The bug was discovered by whitehat researchers approximately 12 days ago. It was publicly announced 5 days ago. We got early word of it from the researchers who initially discovered it, allowing us to patch our systems and ensure all sites behind CloudFlare were not vulnerable. However, we have no way of knowing how long blackhats may have had it. It had been present in the OpenSSL software for the last 2+ years. The…

I'm disgusted they chose to share it with you early and not the major Linux distros...

That works up until it doesn't. Telling n people can work great, telling n+1 people may be complete failure, worse than telling none at all.

It seems (barring evidence saying otherwise) that CloudFlare managed to keep it secret while working on it, so they were proper to have in the n.

Re: The Heartbleed Challenge

#47

Earlier quoted context omitted.

The bug was discovered by whitehat researchers approximately 12 days ago. It was publicly announced 5 days ago. We got early word of it from the researchers who initially discovered it, allowing us to patch our systems and ensure all sites behind CloudFlare were not vulnerable. However, we have no way of knowing how long blackhats may have had it. It had been present in the OpenSSL software for the last 2+ years. The…

I'm disgusted they chose to share it with you early and not the major Linux distros...

There's no way to share such a bug with the major Linux distros and let them deploy a fix to users without making it public at the same time. Even assuming that the distros commit to handle the fix submission and silently repackage openssl (which they don't always do, depending on their policy), the word would get out minutes after it's pushed to the update servers.

So telling major Linux distros == telling the public. At this point, you have to decide whether you want to forewarn big hosters handling millions of sites and billions of visits like Cloudflare, Google, AWS, etc., or not. I don't think there's a good universal answer to this.

Re: The Heartbleed Challenge

#48

You can read more about the CloudFlare Challenge and our own tests on obtaining SSL Private Key material here: http://blog.cloudflare.com/answering-the-critical-question-c... Matthew Prince Co-founder & CEO, CloudFlare

It seems like a "feature" that you'd want your process to store the private key material as low as possible in the address space so that arbitrary read overruns don't run the risk of hitting it. It seems to just accidentally be this way in nginx, but I wonder if it should just be another (tiny) layer in the overall security design.

Shouldn't they be at the top of the address space then overruns would never hit them as they'd start below or does it not work like that.

Re: The Heartbleed Challenge

#49
post #38

It's cool seeing other people's attempts to extract the key in my return buffer. It's like multiplayer microcorruption.com

Which, FWIW, is in the works.

Please please please email out to past participants when it is available, the first one was amazing amounts of fun.
Post reply on HN