Malformed private keys lead to heap corruption in OpenSSL's b2i_PVK_bio | Hacker News Reader

Malformed private keys lead to heap corruption in OpenSSL's b2i_PVK_bio

guidovranken.wordpress.com

25 pointsjlgaddis10 comments

Note that this is a public disclosure of a vulnerability that was NOT included in today's (2016-03-01) OpenSSL release.

> "I reported this one on February 24th, and on February 26th, in response to a different inquiry of mine, I was told that any reports submitted from there on had to wait until the next release. This one apparently didn’t make the cut. I respect the fact that the OpenSSL team has to conform to deadlines and schedules."

> "However, I’ve decided to publicly disclose this one because I think it’s not necessarily more secure to have vulnerable code running on servers for a month of more while attackers, if any (for this vulnerability), are not bound to release cycles and have the advantage of time."

So he's publicly disclosing this even though it's not patched in the latest version, and he only notified the OpenSSL team less than a week ago? That's irresponsible! There's room to debate how long you have to wait before disclosing an unpatched vulnerability to the public, but I think we should all agree it's longer than that.

For serious vulnerabilities, most people (including Google IIRC) would agree that 5 days is sufficient. More importantly, the fact that it wasn't scheduled to be in today's fix means that we have to wait until the next release to get this fix (which will take longer than a week). It's such a trivially exploitable vulnerability that it should be treated as serious.

> ... I think we should all agree it's longer than that.

Yeah, we all don't.

Some opt for full public disclosure 100% of the time (usually with a good reason), some opt for full public disclosure in some cases (such as this one), and others opt only for "responsible" disclosure.

Honestly, it depends on your viewpoints and beliefs and, just like politics, abortions, and gun control, we all have our own opinions and no one is "right" all of the time.

As someone responsible for I-don't-know-how-many servers and network devices servicing thousands of customers, it certainly makes my life easier if I don't have to sit around worrying while I wait for patches for 0-day vulnerabilities. I've been on both sides of it, though, and I can understand why some people go the "full public disclosure" route (and I've done it myself at times).

> There's room to debate how long you have to wait before disclosing an unpatched vulnerability to the public, but I think we should all agree it's longer than that.

I'm fond of immediately, myself. I don't see the point in letting bad agents (many corporations, a variety of seedy open source projects) off the hook. As a consumer of software, I want to know, immediately, when there is a problem. For a variety of systems, I can control the architecture and code myself to mitigate it ASAP.

> I think we should all agree it's longer than that.

I think a week is pretty sufficient. Many consider 48 hours sufficient.

How would you exploit this? What can you gain if you're already able to supply OpenSSL with a private key? Is there a way to supply or tamper with private keys remotely?

I imagine you could exploit neighbors—if, for instance, a load balancer serves multiple clients and allows uploading private keys, this could allow snooping their traffic AS a client.

I'm sure there is some PaaS type system that lets users upload their own keys.

No fix for this yet... great :/

Reply on news.ycombinator.com