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

81–90 of 125 posts

Re: The Heartbleed Challenge

#81

Post by noahm »

voidlogic wrote: post #68
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…

You would think that they could easily work on in advance of incidents who they can trust to with early information. I'd be amazed if Canonical (Ubuntu), Redhat (RHEL) and The Attachmate Group (SUSE) wouldn't show discreet discretion. I don't know about Debian and similar projects, but you would think they could determine this in advance.

I haven't been involved in distro security for a few years, but all this coordination used to happen via a mailing list. Organizations (distro maintainers, OS vendors, security people representing some of the larger/more security sensitive open source projects, etc) would need to apply to be on the list. They'd need to document who would have access to the sensitive materials posted, what their procedure would be for handling, etc. Impact assessment, disclosure timelines, CVE assignments from MITRE, attributions, etc etc would all be coordinated on this list. Fixes would not be pushed to public VCS systems or package repositories before the agreed-upon disclosure date.

AFAICT, none of this happened here. A very small number of organizations was told in advance, but nobody knows what the criteria were to get on this special advance notice list. Given how completely off-guard some really big organizations were caught (yahoo, for instance; all the linux distros, etc), this could have been handled a lot better.

Re: The Heartbleed Challenge

#82

Post by daeken »

benmmurphy wrote: post #56

so i assume any intermediate values from the RSA computations will end up in the heap and may be accessible by an attacker. is it possible to reconstruct the key from these values? i could be missing something but it looks like signing does m mod p and m mod q and part of these operations involves doing a left shift on the divisor (p, q) and this is allocated to a temporary buffer. if these buffers are allocated near…

> maybe this is not leaked or it requires a read at the correct time because these buffers might be trashed by another computation.

As far as I can tell, it's certainly possible for intermediate data to be leaked, but it'd require pretty spectacular timing.

That said, I'm having a bit of a hard time understanding why this challenge exists. If the possibility (even remote) exists that key material was leaked in any form, it should be assumed that the key material was leaked in the worst possible way, and that everything is compromised. They seem to agree, having rolled their keys.

The only real effect I can see from this challenge existing is that people will see it and make the assumption that Heartbleed is "not a big deal, because Cloudflare's keys weren't leaked".

In other words, I think this challenge is harmful to security overall; Cloudflare seems to be doing the right thing, but the messaging here is going to cause people to not follow suit.

Re: The Heartbleed Challenge

#83

Post by noahm »

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.

Every major linux distro has a procedure in place for discreetly preparing updates for pre-disclosure security flaws.

Re: The Heartbleed Challenge

#84

Post by dfc »

fulafel wrote: post #62
dfc wrote: post #59

Earlier quoted context omitted.

I do not understand what you are trying to convey in your message. I never mentioned Cloudflare and neither did the comment I was responding to. What part of my comment led you to believe I was presenting/responding-to a claim made by cloudflare?

The article is about Cloudfare saying their keys are safe. We were discussing implications of someone winning the Cloudfare challenge. You suggested the fall of the challenge would confirm Neel being wrong? I was alluding to Neel's position that that any key leaking is "unlikely" - a much more tenuous position than Cloudfare's. But maybe you meant that he's alrady been proven wrong, and the nsa would be another? Then…

Too often you seem lame jokes like the original comment that require the belief that NSA is leaps and bounds ahead of the world in infosec AND yet NSA is composed of bumbling morons. NSA would be grossly incompetent if they knew how to retrieve the private key AND then informed the world of their offensive capability. This is a basic tenet of intelligence operations, you do not publicize your capabilities to your adversaries.

The renowned clandestine operative B.Smalls, eloquently stated rule #2:

  Never let 'em know your next move
  Don't you know bad boys move in silence and violence?

Re: The Heartbleed Challenge

#85

Post by diminoten »

rubiquity wrote: post #33

If what CloudFlare is saying is true (and I think it is), that the only possibility of Nginx/Apache leaking the private key is on start up due to how low of a memory address the private key is given, is there anything in Nginx/Apache to fire a bunch of dummy requests at itself before accepting public connections? This should effectively bury the memory address that the private key is stored in. Would this be useful i…

Anyone know of a quick way to force nginx to restart?

Re: The Heartbleed Challenge

#86

Post by rubiquity »

diminoten wrote: post #85
rubiquity wrote: post #33

If what CloudFlare is saying is true (and I think it is), that the only possibility of Nginx/Apache leaking the private key is on start up due to how low of a memory address the private key is given, is there anything in Nginx/Apache to fire a bunch of dummy requests at itself before accepting public connections? This should effectively bury the memory address that the private key is stored in. Would this be useful i…

Anyone know of a quick way to force nginx to restart?

Haha, that's what I've been thinking about since this was posted as well :)

Re: The Heartbleed Challenge

#87

Post by conformal »

tptacek wrote: post #39

Didn't Juliano Rizzo already post that he'd been able to extract keys from a server? I'm not clear on the circumstances; for instance, it might have been right after boot, and it might have been Apache, and it might have been FreeBSD.

i suspect the memory accessible by this bug depends a lot on the software, OS and possibly hardware, e.g. on openbsd and bitrig amd64, the amount of memory leaked per exploit is less than 64 KB, closer to 32 KB. if you go much past the 32 KB mark on these OSes, it segfaults.

running an exploit script against one of our own services showed only 1-2 KB of information, most if it being the (public) cert, and the rest zeroed out.

Re: The Heartbleed Challenge

#88

Post by Shish2k »

justincormack wrote: post #51
pbhjpbhj wrote: post #48

Earlier quoted context omitted.

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.

Or you can put in a memory area with unmapped sections on both sides if you are paranoid.

IIRC openbsd's malloc does something like that by default, so every bit of data gets its own protected address space... and then the openssl guys built their own malloc without that feature, to get better performance :(

Re: The Heartbleed Challenge

#89

Post by voidlogic »

noahm wrote: post #83
dubcanada wrote: post #71

Earlier quoted context omitted.

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.

Every major linux distro has a procedure in place for discreetly preparing updates for pre-disclosure security flaws.

If this is really the case, there is no excuse.

Re: The Heartbleed Challenge

#90

Post by teach »

fulafel wrote: post #72
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…

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.

Except that it doesn't work like this. The major Linux vendors are too decentralized for this to work.
Post reply on HN