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

121–130 of 245 posts

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

#121

Post by simias »

kryptiskt wrote: post #46
simias wrote: post #29

Earlier quoted context omitted.

It's a massive open source project that's more than 15 years in the making and supports a massive range of architectures and ever-moving standards. Shit happens, we need to figure out how to make sure it won't happen again at this scale, there's really no need for name calling.

We need to stop have such a fucking accepting attitude about sloppy engineering in security-critical code. People who don't want to be held to a high standard should get out of there and go do something that can't break the internet.

I'm not saying we should accept sloppy engineering in security-critical code, I'm saying that it's pointless to insult people who contribute to free open source projects from the outside.

We want to incite more people to audit and contribute to these projects, not the other way around. Insult the engineering, not the engineers. Or, alternatively, don't insult and propose improvements.

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

#122

Post by return0 »

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…

It's hardly a problem of open-source, it's a problem of open-incentives. While nobody disagrees the project is critical for everyone, are you (or I) willing to make it a priority? It's a essentially a "who will build the roads" issue.

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

#123

Post by belorn »

lucian1900 wrote: post #111
belorn wrote: post #106

Earlier quoted context omitted.

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.

The same license that some libraries inside Starcraft 2 has.

But blizzard must be one of those small companies that do not care about profits, or have no lawyers. No "serious company" or serious software would dare to use LGPL, right?

But instead of arguing license religion, I suggest we move back to the topic of OpenSSL and vulnerabilities.

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

#124

Post by oggy »

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…

There is a formally verified implementation of TLS in F# (comes from Microsoft Research, if anybody cares):

http://www.mitls.org

However, there are gotchas. At this point the TLS protocol has gotten pretty complex. Even the act of just stating what the desired security property are is not simple. Furthermore, understanding what their proof means requires you to go through at least two of their papers (and probably both of their tech reports to grok it fully). Then you need to look at the code itself and the different assertions/assumptions spread throughout, and make sure that those conform to the properties you expect. Even if you are familiar with the field, starting from scratch would probably take you a couple of weeks, just to gain confidence that what they prove is correct. And it might be possible that there are some features of TLS that they don't implement (as you can tell, I haven't taken the couple of weeks to fully understand their stuff).

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

#125

Post by dhimes »

ge0rg wrote: post #24
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…

The heartbleed bug looks exactly like an NSA backdoor: * the protocol extension rfc and implementation are from the same person (who is now working for the largest German IT service contractor; formerly state owned T-Systems). * the extension provides means for one party to send arbitrary data which needs to be returned - a keepalive mechanism would have worked with an empty packet * there is no input validation on n…

If he's working for a German firm now, it wouldn't be an NSA backdoor. Maybe the US isn't the only government with an eye on developing these exploits.

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

#126

Post by Tyrannosaurs »

MrBuddyCasino wrote: post #27
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...

To quote Ted Dziuba: "Anyone who ever told you that swear words have no place in technical discussion is right. They're right, and sadly, they're part of the problem because they miss the point. The sterile word placement that's supposed to support an argument makes any true motivation indistinguishable from all the hired bullshit. [...] However, when someone starts swearing in technical discussion, showing emotion,…

Swearing isn't required for passion. Martin Luthor King didn't have an (expletive of choice) dream, he just had a dream. There are plenty of people who care about their work and manage to express that without swearing. Similarly there are plenty of people who swear about stuff who may well be committed but it's highly questionable about what they're committed to and whether it's to the benefit of the project / team.

If someone does swear (and as it goes, I'm fine with swearing for emphasis and swear way more than I feel I should) they need to be aware that some people find it offensive and that if they don't moderate their behaviour it may be taken very personally which can result in barriers between colleagues and / or low morale.

You can choose to say that that's the person reacting's problem but if you do so you need to be aware of the price that comes with (that they're working in an environment with which they're not completely comfortable which is unlikely to get the best out of them). The alternative is that the swearer moderates themselves (with which they in turn may not be comfortable).

Obviously the better you know your colleagues the more leeway you have. If you've built up trust and togetherness overtime you can get away with anything but even then you need to consider what happens when new people join the team.

But ultimately this is about people and where it's about people there are no absolutes - what works for one group will be kryptonite for another.

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

#127

Post by amboar »

jessaustin wrote: post #116
amboar wrote: post #69

Earlier quoted context omitted.

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.

Sure, so long as the bug is a genuine bug and not a misunderstanding. Debian's openssh valgrind warning springs to mind. Crypto implementations can be subtle and non obvious. Maybe it's crap design for that reason, but it seems like it's what we've got to work with currently.

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

#128

Post by EvanAnderson »

caf wrote: post #114
EvanAnderson wrote: post #83

Earlier quoted context omitted.

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.

I don't know where to go look (mailing list archives? meeting minutes?) to find any discussion about this extension (I'm woefully ignorant of Internet standards processes), but it would certainly be nice to review that discussion.

Given the rather dramatic differences that need to occur in a protocol designed to work over unreliable versus reliable transport, though, it seems like a bad idea to try to keep "parity" between DTLS and TLS. I can see how somebody might see it as "elegant" to do so, but I'd argue they're different animals solving different problems.

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

#129

Post by sentenza »

glomph wrote: post #78
TacticalCoder wrote: post #63

Earlier quoted context omitted.

There's a talk that was given in Belgium / Brussels at FOSDEM2014 two months ago or so by Poul-Henning Kamp (FreeBSD) regarding the NSA and how he'd do it if he had to create holes in software: http://www.youtube.com/watch?v=fwcl17Q0bpk He's talking specifically about OpenSSL quite a lot (basically saying it's too complex to ever be secure and probably received many "security patches" from NSA employees). The entire…

Too be fair it is obviously intended to be a talk on what could be happening and not what certainly is.

It is, however, reasonable to assume that "they" are as smart as we are, so "how would I do it" analysis is quite called for.

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

#130

Post by hrjet »

icebraining wrote: post #71
zmguy wrote: post #61

Earlier quoted context omitted.

Stiff, I think you answered your own question. Intel HIRES them, open source projects don't generally hire people. They sit around and wait for someone to contribute. Are you truly surprised that a volunteer created software is not as rigorously tested as software created by Intel?

Being FOSS doesn't have to mean relying on volunteers. Linux is mostly written by paid developers; why isn't OpenSSL, considering its reach in the commercial world?

Slightly off topic, but do you know whether the paid developers of Linux work on the core kernel, or on device drivers?
Post reply on HN