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

191–200 of 245 posts

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

#191

Post by pritambaral »

lucian1900 wrote: post #160
boolt wrote: post #141

Earlier quoted context omitted.

I would actually be interested in hearing some of the issues related to LPGL in video games and other projects. Are there stories / write ups on this that you could link to or would you mind explaining it some?

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.

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

#192

Post by delinka »

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's a readily-available collection of complicated things (ciphers, digests, cryptographic protocols, etc) that everyone needs. Implementing 'yourself' (your company, whomever) takes lots of time and thus money. It seems the world made the assumption that this open source project was the end-all be-all of cryptographic implementations.

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

#193

Post by andreasvc »

dhimes wrote: post #125
ge0rg wrote: post #24

Earlier quoted context omitted.

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.

There is absolutely no basis for such an inference. It could have been a one off job, he could be undercover, etc. In fact if I were a clandestine organization I would definitely try to recruit people from other countries to make matters appear less obvious.

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

#195

Post by anon1385 »

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?

I doubt very much that RMS would want to add such a clause. Remember, the GPL and LGPL are political tools as much as software licences. They exist to move the world in a certain direction. Adding such clauses would reduce their reason for existing.

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

#196

Post by [deleted] »

derefr wrote: post #188
js2 wrote: post #185

Earlier quoted context omitted.

this behavior is more common than not This has not been my experience. I've contributed to many different projects, large and small (chpasswd, sendmail, apache, git, gerrit, openconnect, homebrew, msmtp, textmate, ...) and never had trouble getting a patch accepted. edit: downvotes, really?

Those projects don't suck, though. When projects (continue to) suck, it's usually because their maintainers suck. When maintainers suck, it's hard to get patches in.

[deleted]

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

#197

Post by lttlrck »

xuu wrote: post #163
mannykannot wrote: post #134

The 'many eyes' hypothesis has now been empirically tested.

Many eyes worked in this case.. It just took a long time to find. The question now is what will it find next and when?

even with a comment in the code...

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

#198

Post by awj »

joosters wrote: post #59
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.

Writing a memory allocator is a great project. Too many programmers believe that malloc() does 'magic' or that what it is doing is simple. After writing your own allocator, you'll never view malloc() as a cheap and simple operation again!

Indeed. The proper thing to do is: write your own malloc, learn an enormous amount from implementing malloc, never ever under any circumstances allow your malloc implementation to enter into production use.

Hopefully the act of writing your own malloc implementation will be enough to convince you not to use it in anger, but it's probably best to be clear on the subject.

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

#199

Post by awj »

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.

That doesn't make the idea futile, especially considering the current alternative. A language runtime focused on safety and a daemon that uses it for that purpose are going to present less of an attack surface than ifdef soup with custom malloc implementations and hand-managed buffer transfers.

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

#200

Post by Sanddancer »

simias wrote: post #29
kzrdude wrote: post #22

Earlier quoted context omitted.

No, that's essential, that line is the message. A secure library should be defensive in coding style and implementation, not sloppy. It should have defaults that err on the safe side, not the fast side, if you have to choose.

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.

Your first statement negates your second. Shit keeps happening because people keep using the excuse that it's a large project. The OpenSSL team needs to take a step back, start proactively auditing their own code, adding unit tests, getting rid of stupidity like having their own caching malloc library. When a project shows a consistent lack of responsibility like the OpenSSL project has, then calling the maintainers irresponsible /is/ the responsible thing to do.
Post reply on HN