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

171–180 of 245 posts

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

#171

Post by jroes »

TacticalCoder wrote: post #63
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…

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…

Here's an interesting thought.

The NSA isn't the only entity who could stand to benefit from a privately held exploit to most SSL implementations. The NSA is also not the only group who could actually accomplish this.

Who's to say there aren't groups out there that are doing this already to steal and profit from corporate information, credit cards, etc.?

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

#172

Post by arca_vorago »

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…

I think now would be great time to reconsider the OpenBSD ipsec debacle in this kind of new light. Correct me if I'm wrong, but doesn't ssh use openssl libraries and the openbsd guys were heavily involved in openssl's development? A lot of people think the closed audit that found a minor unintentional bug was the last word on this subject, but the orginal guy who made the claim posted in 2012 further explaining how the FBI had made this attempt.

Can't wait to find out SSH is comprimised too!

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

#173

Post by andreasvc »

stiff wrote: post #72
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?

I had some problems expressing what bothers me clearly and edited the comment heavily, perhaps it makes more sense now. You're right it is not that surprising, but it's still disappointing that even the most rudimentary best practices are not adopted. Have a look at sqllite for comparison, also an open source project, also in C, certainly less mission critical, and what a difference: https://github.com/smparkes/sqlit…

sqlite does not seem less mission critical to me, and definitely relied on funding:

"D. Richard Hipp designed SQLite in the spring of 2000 while working for General Dynamics on contract with the United States Navy.[7] Hipp was designing software used on board guided missile destroyers" -- http://en.wikipedia.org/wiki/Sqlite#History

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

#174

Post by jwr »

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…

> These are complex to make robust, but they are not hard concepts.

Yes, yes, I didn't quantify my statement with "for production use".

Your sentence I quoted above was exactly my point: they aren't necessarily hard (or at least they don't seem hard), but they are very, very difficult to get right (robust). Getting systems like these to work well in practical production use is more than 80% of the effort.

I wasn't saying that no one should learn how a garbage collector works by implementing one. My point was that no one should implement their own garbage collector for a production system unless they already became an expert in the field of garbage collectors by implementing them for the last 10 years or so. Same goes for memory allocators. If someone thinks these are simple systems, it means they don't know what they don't know.

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

#175

Post by TwoBit »

conformal wrote: post #156
motters wrote: post #88

Earlier quoted context omitted.

My attitude towards complaints about open source projects is that if you think the errors are rudimentary then just submit some patches. If there is not enough test coverage then add one. This applies especially if you believe that the project is critically important. I think what might be happening here is expert syndrome. People may be told that if they're not experts then they shouldn't be reviewing or changing th…

^ this! back in 2010, my business partner, marco peereboom, submitted a patch to openssl to add support for aes-xts. it was coded by joel sing, now a google employee and golang dev. they _didn't even respond to the mailing list email_ and after marco nagged for a reply the response was "we have a different plan for how to implement XTS" (i'm paraphrasing). _2 years later_, they added XTS support. the openssl dev team…

Well maybe his patch really wasn't in line with how it needed to be. I've always hated openssl but I'm not sure this is a valid case.

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

#176

Post by Scene_Cast2 »

motters wrote: post #88
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…

My attitude towards complaints about open source projects is that if you think the errors are rudimentary then just submit some patches. If there is not enough test coverage then add one. This applies especially if you believe that the project is critically important. I think what might be happening here is expert syndrome. People may be told that if they're not experts then they shouldn't be reviewing or changing th…

A while back, I tried submitting a patch to OpenSSL. It was a 3-line change (IIRC) related to the build process - in a particular esoteric setup, the build failed. Got literally zero replies regarding the issue on the mailing list, their IRC channel and on my/their github pull request.

I'd love to contribute more often to other OSS projects. But this behavior is more common than not.

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

#177

Post by TranceMan »

computer wrote: post #165
bhouston wrote: post #57

Earlier quoted context omitted.

The NSA, according to the Snowden docs, can break SSL. No details though: http://blog.cryptographyengineering.com/2013/12/how-does-nsa...

Those documents do not say they can break SSL. They say they focus on SSL, and can break some specific SSL-using services.

Would the specific be the version of openssl being used by the 'target'?

Can't look right now but was this 'bug' introduced at some point in time?

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

#178

Post by mattgreenrocks »

simias wrote: post #121
kryptiskt wrote: post #46

Earlier quoted context omitted.

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.

> We want to incite more people to audit and contribute to these projects, not the other way around

Prepare for some OSS heresy: in many projects, contributions are overrated.

Why? Presumably, the author is the one who feels the most joy/pain of what they've made. They're the ones who've had to grow and prune the code over time. They're the ones who've had to respond to features breaking their mental model sometime. They're the ones trying to make a cohesive abstraction. On crappy projects, the users shoulder more and more of this burden because the author did not.

I've had good luck with contributions in OSS (both making and accepting), but I realize a majority of them are "this isn't working for me, so I added this" without sitting down and considering it's effect on the entire design. I hate rejecting contributions, but if they compromise the project's modeling of the problem, or code quality, then it's for the better.

OSS lends itself to feature creep, just like commercial software. The marketing side of OSS rewards this, by incentivizing you to make more commits (such traction!) and accept changes from everyone (because, community!). New and shiny is a horrible heuristic to use when evaluating infrastructure (read: lots of OSS).

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

#179

Post by ak217 »

jameshart wrote: post #161
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 are certainly large commercial entities who have sufficient incentive to keep OpenSSL secure that they really ought to be contributing actively to the project; I wonder whether Amazon might step up given how badly (and publicly - witness Mojang's taking minecraft services offline and pointing the finger at Amazon as the vendor they were waiting on to fix things - https://twitter.com/notch/status/453529143121309…

I'm not sure that OpenSSL is the project they ought to be contributing to. It looks to be beyond repair architecturally (as a project as well as codebase).

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

#180

Post by 7952 »

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.

Maybe at the OS level? You have to trust the OS anyway so you don't loose anything. Allowing untrusted apps to do encryption makes auditing their activity much more difficult.
Post reply on HN