"OpenSSL has exploit mitigation countermeasures to make sure it's exploitable" • Hacker News Board

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

#151

Post by pbhjpbhj » Wed, Apr 09, 2014, 1:29 PM UTC

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.

I think the intended implication is that he would be an agent for the NSA within that firm. Your second sentence stands however.

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

#152

Post by chriswarbo » Wed, Apr 09, 2014, 1:31 PM UTC

kyllo wrote: post #143

oggy wrote: post #124

Earlier quoted context omitted.

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?

I would imagine it is 'optimised for verification' rather than for speed, ie. the code will be written to follow the structure of the specification.

However, the nice thing about having a verified implementation is that it can be used as the specification (reference implementation) for any other optimisations you want to make.

Such a two-step process is usually much more tractable than trying to verify optimised code directly. This is used extensively by BedRock ( http://plv.csail.mit.edu/bedrock/ ) which uses functional programs as specifications and an assembly-like language for the "real"/optimised implementation. The resulting verification problems are straightforward enough to be mostly automated.

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

#153

Post by EvanAnderson » Wed, Apr 09, 2014, 1:32 PM UTC

noselasd wrote: post #146

EvanAnderson wrote: post #83

Earlier quoted context omitted.

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…

I'm familiar with the paradigm. I've written some code to talk to dodgy embedded devices that don't "talk" unless they have something to say and I have ended up having to use timers. It sucks, to be sure.

I looked back to RFC1122 to get a feel for the nature of TCP keepalives, and I would agree that they're unsuitable for this application.

If we posit that a keepalive mechanism is useful for TLS I'd still argue that a payload is unnecessary because TCP will handle in-order delivery. A NOOP with some random-length padding would have worked just as well.

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

#154

Post by sharpneli » Wed, Apr 09, 2014, 1:34 PM UTC

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.

Even now if OpenSSL would not have made their own memory manager focusing on performance this bug would not have such major consequences.

Frankly they should just accept performance penalties and make a memory manager that focuses on security.

As an example all allocations should be from mmap so that any overflow will automatically segfault (with checks that one doesn't get continuous pages from the OS unmapping selectively to create disjoint areas). Every free should be a munmap etc.

I do also agree that moving this to a separate process would be useful.

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

#155

Post by oggy » Wed, Apr 09, 2014, 1:39 PM UTC

kyllo wrote: post #143

oggy wrote: post #124

Earlier quoted context omitted.

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?

No, you're right on target. They are using non-optimized data structures, and rely on (Bouncy Castle's) managed code for encryption. From their paper, the throughput is around 10x slower than OpenSSL (but much closer to JSSE). My guess is that one could probably speed this up significantly, while still retaining the guarantees, but that's probably less interesting to these guys.

As for Mono or .NET, I assume so (AFAIK that's the only way to run F# applications).

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

#156

Post by conformal » Wed, Apr 09, 2014, 1:40 PM UTC

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…

^ 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 is not responsive, doesn't accept contributions and generally speaking suffers from "you're not an expert" syndrome. look how expertly they've managed their project!

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

#157

Post by philh » Wed, Apr 09, 2014, 1:40 PM UTC

sentenza wrote: post #129

glomph wrote: post #78

Earlier quoted context omitted.

Too be fair it is obviously intended to be a talk on what could be happening and not what certainly is.

It is, however, reasonable to assume that "they" are as smart as we are, so "how would I do it" analysis is quite called for.

Yes, but it's not reasonable to assume that our armchair "how I would do it" theorizing is, in fact, how they would do it. We can assume that they have come up with the idea, but maybe they discarded it for reasons that aren't obvious to us.

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

#158

Post by iSnow » Wed, Apr 09, 2014, 1:42 PM UTC

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…

Well, I can code myself out of a hole I have coded myself into. But I guess the world is a better place because I don't try to help crypto projects by contributing.

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

#159

Post by oddevan » Wed, Apr 09, 2014, 1:43 PM UTC

boolt wrote: post #141

lucian1900 wrote: post #135

Earlier quoted context omitted.

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?

Based on some informal research I did ~10 years ago (i.e. I ready the LGPL as a high school student), the LGPL requires, among other things, an end-user license allowing reverse engineering. The LGPL isn't just "my code is GPL, the rest of the program is whatever"; it puts forth some requirements for the entire finished product that are either impractical (must include source code) or illegal (would violate NDA or other license terms for the console libraries) for console games.

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

#160

Post by lucian1900 » Wed, Apr 09, 2014, 1:45 PM UTC

boolt wrote: post #141

lucian1900 wrote: post #135

Earlier quoted context omitted.

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?

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 the source to their version of the library.

In fact, even if they released the source to their whole game (something the publisher would never allow) the LGPLv3 still cannot be met because of the anti-Tivoisation clause, which stipulates that users must be able to run their own compiled version of the software.