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

111–120 of 245 posts

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

#111

Post by lucian1900 »

belorn wrote: post #106
stiff wrote: post #54

It is surprising that a project that is quite mission critical is completely at the bottom of the scale when it comes to how much the development process is oriented toward reliability. There are no systematic unit tests, no systematic documentation, the best you get is a bunch of disorganized integration tests, so it is not even at the level you would expect for a decently maintained business project: https://github…

Generalization in this case is really unhelpful, since there is almost no diversity in SSL libraries. There is 3 of them, but almost everyone uses openssl. One case do not make a trend at all, and two cases is the worst statistical proof there is for trends. On the positive side, open source model of development do allow projects to use not only what is common, but also the exciting fronter regarding security models.…

gnutls has also had vulnerabilities and it gets less attention, I guess you mostly got lucky.

Sadly, it'll never become popular because of the license.

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

#112

Post by jrochkind1 »

this_user wrote: post #48
bhouston wrote: post #26

Earlier quoted context omitted.

> no need for tinfoil hat theories 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 security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA. For example of NSA efforts in related areas (which I figured you would already know): http://www.cnbc.com/id/101301261 htt…

There is a difference between infiltrating companies and deliberately introducing a bug that compromises a large chunk of the Internet. I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

> I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

Don't we actually already have evidence of other cases of the NSA adding backdoors to widely used systems, exploitable by anyone aware of them? Isn't that what the elliptic curve backdoor was? http://www.wired.com/2013/09/nsa-backdoor/all/

Apparently your assumption is quite not safe to assume.

I guess the NSA either figures nobody else will notice the backdoor, or just doesn't care. I guess only they know their motivations.

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

#113

Post by rbanffy »

this_user wrote: post #48
bhouston wrote: post #26

Earlier quoted context omitted.

> no need for tinfoil hat theories 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 security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA. For example of NSA efforts in related areas (which I figured you would already know): http://www.cnbc.com/id/101301261 htt…

There is a difference between infiltrating companies and deliberately introducing a bug that compromises a large chunk of the Internet. I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

> the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

If possible, yes. However, if they were indeed responsible for this, they'd probably have a couple honeypots to detect exploitation by third parties. If they considered the third party harmless, they could decide whether the vulnerability should be "independently discovered" or not.

Planting a complicated exploit would be harder and increase the risk it could be traced back to them.

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

#114

Post by caf »

EvanAnderson wrote: post #83
this_user wrote: post #65

Earlier quoted context omitted.

* T-Systems was never state-owned. The German Federal Post used to be state owned but was split into separate post, communications and banking divisions in 1995. Deutsche Telekom IPO'd in 1996. T-Systems was founded in 2000 as a subsidiary of Deutsche Telekom. The German state currently holds around 15% of Deutsche Telekom stock. * RFC 6520 was published in February 2012. At that time Robin Seggelmann wasn't employed…

This is the first that I've had time to actually sit down and look at code, the RFC, etc, and I'm scratching my head. The rationale for the payload for DTLS (sent over UDP) is reasonable, but I'm scratching my head over why the payload is even there for TLS. I guess there's some logic in making the protocol the same irrespective of underlying transport, but the payload is completely redundant for reliable protocols,…

It's easy to see why, without the benefit of hindsight, one might think that the minimal approach was to have the same extensions apply to both DTLS and TLS.

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

#115

Post by rbanffy »

simias wrote: post #5
bananas wrote: post #2

Great analysis. Theo is always up front on this sort of stuff which is commendable.

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

You must be joking. "OpenSSL is not developed by a responsible team" is probably the most benign criticism Theo has ever issued.

And he's quite right. This is a class of bug that should not exist or, at least, be restricted to the OSs where "malloc() performance is bad enough" to justify using their own implementation. Memory management is a non-trivial problem.

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

#116

Post by jessaustin »

amboar wrote: post #69
joosters wrote: post #40

Earlier quoted context omitted.

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!

I don't know what the gp's skills are, but assuming he's not a computer security professional then the 'other people should do this' club is exactly the club he should be in. Would you trust his audit of the code if he wasn't heavily experienced? it's the same case as "don't roll your own crypto".

There's a difference between "trusting his audit of the code" and "trusting his code". Any interested and motivated person can audit code. If nothing is found, that might not prove much. But if a vulnerability is found, the audit was worthwhile from some perspective.

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

#117

Post by lazyjones »

sharpneli wrote: post #38
lazyjones wrote: post #18

Earlier quoted context omitted.

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.

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

Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe.

> One just needs to keep on looking for exploits and keep on patching them.

This approach hasn't worked in the past and will not work in the future either. Especially when we start with the existing, desolate and probably thoroughly compromised codebases.

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

#118

Post by caf »

jrochkind1 wrote: post #112
this_user wrote: post #48

Earlier quoted context omitted.

There is a difference between infiltrating companies and deliberately introducing a bug that compromises a large chunk of the Internet. I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.

> I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails. Don't we actually already have evidence of other cases of the NSA adding backdoors to widely used systems, exploitable by anyone aware of them? Isn't that what the elliptic curve backdoor was? http://www.wired.com/2013/09/nsa-backdoor/all/ Apparently your assumption is quite not…

The mooted backdoor in the Dual-ECDRBG involves the possibility that the public parameters were generated based on some secret values, such that knowing the secret values allows you to break the generator.

It doesn't allow just anyone to break it - merely knowing the backdoor is there isn't enough.

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

#119

Post by bananas »

SixSigma wrote: post #101
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 is such a "character" that his "work" has been incorproated into the plan9 spin-off 9front as a theo (1) specific fortune file. http://man.cat-v.org/9front/1/fortune

The mg implementation that ships with OpenBSD has a fair few insults in it as well under the command "theo":

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c?...

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

#120

Post by joshuak »

stiff wrote: post #54

It is surprising that a project that is quite mission critical is completely at the bottom of the scale when it comes to how much the development process is oriented toward reliability. There are no systematic unit tests, no systematic documentation, the best you get is a bunch of disorganized integration tests, so it is not even at the level you would expect for a decently maintained business project: https://github…

I agree this is incredibly surprising. Even beyond typical production testing it seems to me that critical infrastructure crypto should have a formalized testing structure based on logic and information theory (as I had assumed OpenSSL did). Build trust from the bottom up. Test that only known affirmatively tested primitives are used for memory allocation, and other known sensitive operations. Things like buffer overflow, range checking, executable code in data, etc. can all be easily tested.

There is a lot of work in crypto research about trust in the logical and mathematical sense, why is this work not applied to software testing at least for infrastructure crypto?

P.S. By way of incentivizing this work... seems like a pretty good dissertation topic.

Post reply on HN