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

"OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

article.gmane.org

Post reply on HN
Print view View original

31–40 of 245 posts

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#31

Post by ensmotko »

bhouston wrote: post #21

Has anyone started a rumor yet that the NSA infiltrated the OpenSSL development team to make OpenSSL ineffective and full of holes? The convoluted code of OpenSSL alone (from yesterday's Hackernews post) seems like a great way to add all sorts of "bugs" inadvertent or not. Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet se…

Check out phk's fosdem talk[0]. I've linked to the the part where he talks about openSSL, but I'd suggest watching the whole thing. I'm now starting to believe the talk wasn't a joke at all...

[0] https://www.youtube.com/watch?v=fwcl17Q0bpk&feature=youtu.be...

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#32

Post by maxbucknell »

If there are so many problems with OpenSSL, why are there no alternatives that are readily available and anywhere near as functional?

The whole internet runs OpenSSL, but why hasn't anyone tried to do something different? I know it's complicated, but if a few big companies really chose to put some muscle behind it, it could happen, right?

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#33

Post by supersnap »

This is pretty much proof that open source fails to maintain security software in a responsible way.

Look kids ssl is not that hard to implement.

Time to let the cargo cult go have a campfire and sing songs.

This is too important to leave to lazy paid for nothing programmers who want to write lazy ass c code after too many beers.

Grow up

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#34

Post by Gigablah »

baq wrote: post #13
simias wrote: post #5

Earlier quoted context omitted.

Could have done without the final line though, but I guess it's his equivalent of a signature...

theo's an asshole, but he's quite often right. i don't like his attitude too, but it has to be said that in this particular case, consequences have been - and/or will be - extraordinary.

"OpenSSL is not developed by a responsible team" is downright benign compared to "OpenSSL is written by monkeys".

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#35

Post by madaxe_again »

simias wrote: post #23
bhouston wrote: post #21

Has anyone started a rumor yet that the NSA infiltrated the OpenSSL development team to make OpenSSL ineffective and full of holes? The convoluted code of OpenSSL alone (from yesterday's Hackernews post) seems like a great way to add all sorts of "bugs" inadvertent or not. Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet se…

Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy. That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible. Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL bu…

You have kept up to date with the news, right? Truecrypt, RSA... OpenSSL is low-hanging fruit by comparison. Of course it's back doored - probably more than once.

You're right that it needs cleaning - it needs a full audit. I'm surprised in the light of the Snowden revelations that none of us have suggested this sooner, but hindsight is a bitch and all that.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#36

Post by arethuza »

pwang wrote: post #25
jwr wrote: post #9

Earlier quoted context omitted.

At a first approximation, no one should write their own memory allocator. Just as no one should write their own garbage collector, and no one should write their own filesystem. All these subsystems have one thing in common: they are incredibly complex and very hard to get right, but seem easy on the outside.

I disagree. These are complex to make robust, but they are not hard concepts. I think everyone should write their own GC, write a filesystem, and handle their own memory layer, at least once. Treating lower levels of the stack as "too complex, there be dragons, just write some Javascript that hits RESTful API for JSON" is a great way to ensure you never progress as a software dev or an engineer. I agree that reinvent…

I think the important part of the previous comment is "At a first approximation" - of course there is nothing wrong in writing code with the primary goal of personal understanding, but re-inventing the wheel when there are potentially very serious consequences for others is hubris (unless, of course, you have a really good reason why, NIH not being a good reason in my book).

[NB Ken Shirriff's blog articles on Bitcoin are a superb example of someone coding in an effort to understand a system - but I don't think he is attempting to write a real Bitcoin library]

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#37

Post by recentdarkness »

reidrac wrote: post #8
antocv wrote: post #6

Earlier quoted context omitted.

GnuTLS exists. And NSS in mozilla. Probably others too.

cURL makes a nice comparison: http://curl.haxx.se/docs/ssl-compared.html GnuTLS had its own problems recently (see: http://www.gnutls.org/security.html ), and regarding NSS... I couldn't find a proper public "security" page for it (eg, release notes for 3.16 point to CVE-2014-1492; but the link to the bugzilla issue is not public), so I don't know. Obviously a good security record doesn't imply things like a good cod…

Regarding the NSS CVE-2014-1492: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-14...

Quote: "The cert_TestHostName function in lib/certdb/certdb.c in the certificate-checking implementation in Mozilla Network Security Services (NSS) before 3.16 accepts a wildcard character that is embedded in an internationalized domain name's U-label, which might allow man-in-the-middle attackers to spoof SSL servers via a crafted certificate."

Edit: Added Quote

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#38

Post by sharpneli »

lazyjones wrote: post #18
doe88 wrote: post #11

Earlier quoted context omitted.

Not sure which one I'd pick; all of the main libraries seems to either have had very bad issues reported at one point or another or are maybe not used enough to inspire enough conficdence; anyway here is a list https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementati...

Perhaps this task should be moved away from libraries (which in some cases are even statically linked and hard to update) into a well-audited daemon, written in a safe language. Or even into several separate daemons for better protection (each with the least privileges required and minimal interface), for example one for handling keys / signing requests only.

And then we'd have potential exploits both in the daemon and in the safe language runtime/compiler.

There is no silver bullet for this. One just needs to keep on looking for exploits and keep on patching them.

However there is a lot that can be improved on OpenSSL side. I hope they change their memory allocation strategy after this.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#39

Post by davidw »

maxbucknell wrote: post #32

If there are so many problems with OpenSSL, why are there no alternatives that are readily available and anywhere near as functional? The whole internet runs OpenSSL, but why hasn't anyone tried to do something different? I know it's complicated, but if a few big companies really chose to put some muscle behind it, it could happen, right?

This sums up some of the difficulties with the production of open source software:

https://en.wikipedia.org/wiki/Public_good

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#40

Post by joosters »

madaxe_again wrote: post #35
simias wrote: post #23

Earlier quoted context omitted.

Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy. That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible. Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL bu…

You have kept up to date with the news, right? Truecrypt, RSA... OpenSSL is low-hanging fruit by comparison. Of course it's back doored - probably more than once. You're right that it needs cleaning - it needs a full audit. I'm surprised in the light of the Snowden revelations that none of us have suggested this sooner, but hindsight is a bitch and all that.

Lots of people have suggested it. Very few people have dedicated their time to helping do it, though. Welcome to the 'other people should do this' club!
Post reply on HN