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

141–150 of 245 posts

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

#141

Post by boolt »

lucian1900 wrote: post #135
belorn wrote: post #123

Earlier quoted context omitted.

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.

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?

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

#142

Post by caf »

baq wrote: post #13
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...

theo's an asshole, but he's quite often right. i don't like his attitude too, but it has to be said that in this particular case, consequences have been - and/or will be - extraordinary.

Well, really the consequences would have been virtually the same either way, since the number of OpenSSL deployments where the system malloc uses guard pages is a rounding error.

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

#143

Post by kyllo »

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…

My assumption would be that this formally verified implementation is not optimized, and therefore runs rather slowly compared to the C implementations. Plus it requires the .NET framework or Mono to run it. Am I off base?

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

#144

Post by jordigh »

return0 wrote: post #122
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.

Yeah, free software isn't a development model and it doesn't mean it's made by amateurs. As another prominent free project with a much better track record for security and stability, consider OpenSSH, the crown jewel of the OpenBSD crowd, a free software distribution itself popularly renowned for its security. Theo's criticism here of OpenSSL carries a lot of weight.

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

#145

Post by rwmj »

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?

This has some information although not exactly what you wanted to know:

http://lwn.net/Articles/579081/

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

#146

Post by noselasd »

EvanAnderson wrote: post #83
this_user wrote: post #65

Earlier quoted context omitted.

* T-Systems was never state-owned. The German Federal Post used to be state owned but was split into separate post, communications and banking divisions in 1995. Deutsche Telekom IPO'd in 1996. T-Systems was founded in 2000 as a subsidiary of Deutsche Telekom. The German state currently holds around 15% of Deutsche Telekom stock. * RFC 6520 was published in February 2012. At that time Robin Seggelmann wasn't employed…

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,…

If you ever implement connection oriented protocols, you will very quickly find the need for a heartbeat mechanism - otherwise you have no way of telling whether the remote end is dead, or if is just busy creating data for you/doesn't have any data for you right now.

Not having heartbeats, you end up relying only on arbitrary timers to time out your connections, which are far from optimal, or you end up relying only on the underlying protocol which is not enough in most cases.

TCP doesn't provide that for you. (TCP does provide keepalives, intended for other means, they might be a poor mans substitute, but they arn't exposed to the TCP user in a particularly useful way - it's also the wrong layer for this problem)

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

#147

Post by ef4 »

davidw wrote: post #39
maxbucknell wrote: post #32

If there are so many problems with OpenSSL, why are there no alternatives that are readily available and anywhere near as functional? The whole internet runs OpenSSL, but why hasn't anyone tried to do something different? I know it's complicated, but if a few big companies really chose to put some muscle behind it, it could happen, right?

This sums up some of the difficulties with the production of open source software: https://en.wikipedia.org/wiki/Public_good

That really doesn't illuminate anything, because you'd also need to explain why open source has been spectacularly successful generating other public goods (linux and others).

The economics of open source are pretty clear at this point. The software industry spends a lot of money supporting open source, because it's in their own interest to do so -- it's cheaper to share the costs than to build your own infrastructure from scratch every time, when the infrastructure is not part of your competitive advantage.

This particular bug was found by people that Google pays to audit open source code all day, in an effort to improve said code.

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

#148

Post by davidw »

ef4 wrote: post #147
davidw wrote: post #39

Earlier quoted context omitted.

This sums up some of the difficulties with the production of open source software: https://en.wikipedia.org/wiki/Public_good

That really doesn't illuminate anything, because you'd also need to explain why open source has been spectacularly successful generating other public goods (linux and others). The economics of open source are pretty clear at this point. The software industry spends a lot of money supporting open source, because it's in their own interest to do so -- it's cheaper to share the costs than to build your own infrastructur…

> open source has been spectacularly successful generating other public goods (linux and others).

No one doubts that some open source software has been very successful. What I'm not sure of is whether levels of open source provisioning are optimal: maybe there should be 10X what there is now. Maybe Linux should dominate the desktop world, but does not due to lack of funding. This is Bastiat's "what is not seen" - what we have now is good, but perhaps it could be better. Maybe a lot better, under different circumstances.

Also, that link mentions Coasian solutions, and privileged goods, which between them explain a lot about open source software, no?

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

#150

Post by danielweber »

lazyjones wrote: post #117
sharpneli wrote: post #38

Earlier quoted context omitted.

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. Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe. > One just needs to keep on looking for exploits and keep on patching them. This approach hasn't worked in the p…

Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe.

This will prevent the prior vulnerability. Will it prevent the next one? Do you know what it won't make the next vulnerability worse?

A year or two ago I had to deal with a bunch of people complaining that the embedded device my team was selling was vulnerable to BEAST, because their scanning tool told them it was. I wrote a long essay for the support team about how BEAST is exploited and it's really hard to do it against a limited purpose control GUI with no publicly routeable address, and this worked for about half the people who complained. For the others we had to turn on RC4, which may have been even worse, but now their tool wasn't complaining at them so they were happy, even though they may have been worse off.

Thankfully my old team didn't rush to the new OpenSSL version so they got to avoid the past 48 hours being complete shit for them.

There aren't clean answers. Like with financial regulation, what you do to make sure the last thing never happens again may create the next thing.

Post reply on HN