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

211–220 of 245 posts

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

#211

Post by endeavor »

tomphoolery wrote: post #162
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 also wonder how much in the end the big institutions care about this stuff. Well, if they did care more, you'd see engineers from Intel, IBM, et. al., contributing to the project in droves like they do with the Linux kernel.

Chrome and Firefox both use NSS. I would assume that the big institutions looked at OpenSSL and decided their money would be better invested in other projects.

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

#212

Post by lern_too_spel »

mikevm wrote: post #181
ak217 wrote: post #179

Earlier quoted context omitted.

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).

How in the heck is this mess of a project so popular?

It was developed outside the US at a time when the US had export restrictions on strong crypto. Now that those restrictions are gone, anybody can just use NSS instead.

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

#213

Post by ctz »

Scene_Cast2 wrote: post #176
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…

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.

I've also submitted patches to OpenSSL and been entirely ignored[1]. The latest of which strictly improved testing, documentation and included a detailed study and write-up of actual bugs in OpenSSL and downstream code[2].

My conclusion was that the OpenSSL project is not interested in external contributions.

[1]: https://www.mail-archive.com/openssl-dev@openssl.org/msg3362...

[2]: http://jbp.io/2014/01/16/openssl-rand-api/

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

#214

Post by lern_too_spel »

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…

"Big institutions" already did that. It's called NSS.

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

#215

Post by mpyne »

spacemanmatt wrote: post #91
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 always assumed (note past tense) that their secrets stay pretty secret, and their wide-open backdoors will not get knockers.

They don't assume that.

I don't see why people think that NSA is simultaneously genius-level forces of the Illumanti architecting events that will culminate years later, and yet would make the rookie level mistake of introducing a backdoor that is protected only by obscurity.

They know other security services understand how to decompile code (or read the original source).

More importantly, they know that critical government services they can't predict will end up possibly running things like their broken version of OpenSSL. There's a FIPS standard, of course, but note that the Heartbleed page made quite clear that FIPS is vulnerable too.

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

#216

Post by Guvante »

pritambaral wrote: post #191
lucian1900 wrote: post #160

Earlier quoted context omitted.

I'm not aware of any long form text on this, but the issue is relatively straightforward. A publisher hires a studio to make a game, which then gets published on platforms that actively prevent users from (compiling and) running their own software (consoles, iOS). Since the user is not provided with the tools to replace a library used in a game, the terms of the LGPL cannot be met even if the studio were to release t…

Would a clause in LGPLv3 that exempts the publisher/distributor from limitations beyond their control (console/iOS restrictions) help? Also, I think the the user isn't prevented from recompiling and running altogether; a user can get a developer account. Although, I guess that presents an additional cost, something (L)GPL might be against.

> Would a clause in LGPLv3 that exempts the publisher/distributor from limitations beyond their control (console/iOS restrictions) help?

Tivo would just create a complicated enough corporate structure to provide the same shroud for themselves and will then be able to satisfy all requirements.

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

#217

Post by jude- »

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…

As I said in a similar post, their proofs show that their implementation is logically correct--their implementation will behave according to their formalization of the RFCs.

This says nothing about how secure it is with respect to side-channel attacks. For example, they admit that they did not model time in their proofs, so they have NOT proved that they are immune to timing attacks. Moreover, F# runs on top of the unverified CLI--bugs in the CLI can be used to break miTLS.

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

#218

Post by laumars »

mikevm wrote: post #181
ak217 wrote: post #179

Earlier quoted context omitted.

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).

How in the heck is this mess of a project so popular?

Are the alternatives much better? GnuTLS has had it's fair share of embarrassing bugs too and I can't think of a 3rd open source product that's as mature.

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

#220

Post by charonn0 »

awj wrote: post #202
nosefrog wrote: post #169

Earlier quoted context omitted.

Yes, and that's how this bug was found.

So "many eyes" means "paid researches at Google and a security firm"? Also, this bug was in place for what, two years? If the many eyes hypothesis has a two year lead time to find bugs this severe, we can stop talking about it because it's fucking worthless.

> two years

If that's how we're measuring things, then closed source isn't going to win either, e.g. [1].

[1]: http://www.computerworld.com/s/article/9146820/Microsoft_con...

Post reply on HN