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

The Heartbleed Challenge

cloudflarechallenge.com

Post reply on HN
Print view View original

71–80 of 125 posts

Re: The Heartbleed Challenge

#71

Post by dubcanada »

euank wrote: post #57
giovannibajo1 wrote: post #47

Earlier quoted context omitted.

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 publi…

Not so; companies like RHEL understand the importance of disclosure timelines and won't leak it early. The importance of telling large distros doesn't lie in them immediately releasing a fix; it lies in them being able to prepare a package with the fix before the announcement, and then exactly when the announcement happens, they can publish the package (and possibly do something to make it propagate faster to their d…

It doesn't matter if they show "responsibly disclosed" all their repos are publicly available to see, it takes one person looking through commits then going wtf is this followed by a quick look at the code and a blog post to make this a wildfire.

Re: The Heartbleed Challenge

#72

Post by fulafel »

giovannibajo1 wrote: post #47
voidlogic wrote: post #40

Earlier quoted context omitted.

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 publi…

No, it works like this: everyone gets their fix ready hush hush, and on an agreed date it's made public, and vendors hit the "publish" button more or less simlultaneously.

Re: The Heartbleed Challenge

#73

Post by loopdoend »

daedalus2027 wrote: post #63

I have got this header: OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 Host: www.cloudflarechallenge.com Accept: / PrivateKey: EiS3mdBFanVEaeRkk4otJRRHFTGi6tVZUJKl5v7rGpjJnY0gTn4PWSlOJqA2l32o Content-Length: 1721 Content-Type: application/x-www-form-urlencoded Expect: 100-continue http://pastebin.com/FLcsYDfE

That is somebody trolling you by modifying their request headers.

Re: The Heartbleed Challenge

#74

Post by webXL »

tomvangoethem wrote: post #54

Note that by visiting, your IP and referer become accessible by anyone running an heartbleed exploit: 93.142.x.x - - [11/Apr/2014:10:44:36 -0400] "GET /heartbleed HTTP/1.1" 200 1148 "https://news.ycombinator.com/" "Mozilla/5.0 (Windows NT 6.1; WOW64)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"

Whoops, too late. Were you able to get that info from actually running the exploit?

Re: The Heartbleed Challenge

#75

Post by kaivi »

danielweber wrote: post #15

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

This is fun, indeed.

Has anyone already made a patch for this bug, where the lib returns random data instead of actual heap chunks?

Re: The Heartbleed Challenge

#76

Post by d0ne »

We will add a $10,000 bounty for the first published and confirmed successful completion of this challenge.

Conditions:

1) CloudFlare confirms success.

2) The winner publishes their solution, including source, publicly.

3) Promptly send the link to the publication to [adam | ionicsecurity | com] (for tracking the order of submissions)

Good luck!

Re: The Heartbleed Challenge

#78

Post by mikeash »

I wonder if one could use this server (or, of course, any other vulnerable server, but the hostname on this one is nice) for phishing people. For example, e-mail them the link, then try to snarf the referer header out of the server's memory in the hopes that their webmail URL contains something juicy, or give them a fake form that POSTs interesting data to it. Probably far-fetched, but it's amusing to consider.

Re: The Heartbleed Challenge

#79

Post by michaelt »

dubcanada wrote: post #71
euank wrote: post #57

Earlier quoted context omitted.

Not so; companies like RHEL understand the importance of disclosure timelines and won't leak it early. The importance of telling large distros doesn't lie in them immediately releasing a fix; it lies in them being able to prepare a package with the fix before the announcement, and then exactly when the announcement happens, they can publish the package (and possibly do something to make it propagate faster to their d…

It doesn't matter if they show "responsibly disclosed" all their repos are publicly available to see, it takes one person looking through commits then going wtf is this followed by a quick look at the code and a blog post to make this a wildfire.

I think the notion is the distro security team codes and tests a patch, but doesn't commit the code to public repos or release the patch publicly until an agreed-upon disclosure date.

Re: The Heartbleed Challenge

#80

Post by SchizoDuckie »

remon wrote: post #23

I must be the only one that's pretty much done with having to read about heartbleed.

My guess is that if this gets exploited this is going to be used in combination with another (yet unknown) bug. Now all we can do is set back and hope the white hats prevail
Post reply on HN