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

131–140 of 245 posts

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

#131

Post by blazespin »

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…

Reality is NSA has to do very very little to make this happen. Tiny nudges here and there. Profit motive encourages people to move towards complexity. Simple software commodifies too quickly.

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

#132

Post by rbanffy »

naveen99 wrote: post #98
laggyluke wrote: post #28

Earlier quoted context omitted.

They say you shouldn't write your own crypto either :)

Ignore people who say that. Crypto doesn't need to be complicated.

There is a difference between complex and complicated. Crypto is a complex issue, with some subtleties that elude too many people. Low-level crypto, like this, has many small little details (such as allocating and deallocating buffers) that make it very complicated.

You are right: it could be much simpler.

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

#133

Post by JetSpiegel »

recentdarkness wrote: post #15
riffraff wrote: post #12

Earlier quoted context omitted.

fedora is apparently trying to consolidate all crypto to NSS https://fedoraproject.org/wiki/FedoraCryptoConsolidation

That page has not been changed since May 7th 2013, I am not sure that this is currently still actively pursued. Also I haven't seen this on the proposals for F21

https://fedoraproject.org/wiki/Releases/21/ChangeSet#System-...

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

#135

Post by lucian1900 »

belorn wrote: post #123
lucian1900 wrote: post #111

Earlier quoted context omitted.

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.

You know as well as I do that LGPL is not always an option. A very visible case is console games.

But yes, let's go back to lamenting the state of crypto libraries, we can at least agree on that.

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

#136

Post by JabavuAdams »

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…

The failure mode with this approach is that it disallows coaching.

There may be some bug in a library that's similar to what I do for my day job, and I spot it immediately. Or perhaps I've seen the inevitable results of certain design decisions play out in multiple organizations.

I may not have time to code up a patch. Frankly, I've got about 5 projects on the go besides work and kids.

So, FOSS projects may lose out on that kind of expertise that could easily be crowd-sourced if it didn't ask so much of contributors.

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

#137

Post by JabavuAdams »

oggy wrote: post #124
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 bo…

Sounds complicated. Let's just build an AI that can program, and trust it when it says it's not spying on us.

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

#138

Post by userbinator »

lttlrck wrote: post #110
a8000 wrote: post #49

Earlier quoted context omitted.

I don't understand this attitude, if something is incredibly complex and very hard to get right, this can indicate that there is a mismatch between the tools you use to implement it and what you should use. With the right language it might be much more pleasant to implement: Consider for example https://github.com/GaloisInc/halfs a filesystem implemented in Haskell, I think it has ~10000loc It can also mean that exis…

I don't understand the point you are making with the filesystem. LOC as a single point of reference is useless.

10kLOC of Haskell for a filesystem seems like an awful lot, especially when considering how much more concise and higher-level Haskell is supposed to be compared to languages like C. Maybe filesystem code just don't fit too well into the functional paradigm?

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

#139

Post by abrahamsen »

hrjet wrote: post #130
icebraining wrote: post #71

Earlier quoted context omitted.

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?

Both, as they provide the bulk of the code. It would be more illuminating to examine where the unpaid volunteers contribute. My guess would be device drivers, but I don't know.

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

#140

Post by JabavuAdams »

jwr wrote: post #9
btown wrote: post #3

This should be a case study about why people developing system-critical software shouldn't write their own memory allocators.

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.

For most uses, you don't really have to get them right, though. The problem is knowing when yes, you absolutely do need to get this right.

The cost in effort is highly non-linear. It may be fairly straightforward to get the 80% solution. I agree that it's a problem when devs bring their home-grown 80% solutions to the table when you need a 99% solution.

I make games. No one dies if there's a bug in the AI. No one may even notice.

Post reply on HN