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

181–190 of 245 posts

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

#181

Post by mikevm »

ak217 wrote: post #179
jameshart wrote: post #161

Earlier quoted context omitted.

There are certainly large commercial entities who have sufficient incentive to keep OpenSSL secure that they really ought to be contributing actively to the project; I wonder whether Amazon might step up given how badly (and publicly - witness Mojang's taking minecraft services offline and pointing the finger at Amazon as the vendor they were waiting on to fix things - https://twitter.com/notch/status/453529143121309…

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?

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

#182

Post by mattgreenrocks »

simias wrote: post #5
bananas wrote: post #2

Great analysis. Theo is always up front on this sort of stuff which is commendable.

Could have done without the final line though, but I guess it's his equivalent of a signature...

The lower you are on the stack, the more you need quality. And the more you need quality, the more likely you are to run into hackers with 'tough love' personalities, because they simply cannot tolerate poor excuses for code.

How they express it is a reflection of their character, but they will let you know when you screw up. Theo was extremely tact given the enormous impact of this bug.

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

#183

Post by ralfd »

EvanAnderson wrote: post #128
caf wrote: post #114

Earlier quoted context omitted.

It's easy to see why, without the benefit of hindsight, one might think that the minimal approach was to have the same extensions apply to both DTLS and TLS.

I don't know where to go look (mailing list archives? meeting minutes?) to find any discussion about this extension (I'm woefully ignorant of Internet standards processes), but it would certainly be nice to review that discussion. Given the rather dramatic differences that need to occur in a protocol designed to work over unreliable versus reliable transport, though, it seems like a bad idea to try to keep "parity" b…

Maybe the payload is used for a sequential id number?

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

#184

Post by tootie »

ge0rg wrote: post #24
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…

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…

http://en.wikipedia.org/wiki/Hanlon's_razor

This bug is too general and too wide open to be deliberate. Any college student could write code this shitty. An engineered flaw would have to be more subtle.

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

#185

Post by js2 »

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.

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?

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

#186

Post by BrainInAJar »

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.

> All these subsystems have one thing in common: they are incredibly complex and very hard to get right, but seem easy on the outside.

And have teams of operating systems engineers whose entire existence is predicated on them, rather than them just being an afterthought so you can get some other stuff done. If the OS does it, you shouldn't.

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

#187

Post by rst »

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…

TCP heartbeats certainly will let you know if the remote end is entirely dead.

They won't let you know if the application process is jammed up --- but TLS hearbeats won't do that for you either! (For example, it's common to have the crypto handled by front-end processes, with the application logic elsewhere.) So if that's what you want, then you need heartbeats at the application layer, not in TLS.

Given all that, the case for hearbeats at the TLS layer for TLS over TCP seems ... weak. Particularly since simply having them there violates the commonly cited best practice that security kernels should be kept small. And this violation has already had disastrous consequences.

Besides, for all the times I see people making this argument, I've yet to see them cite an example of a real problem in a real world deployment for which TLS hearbeats were used, and turned out to be the best solution.

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

#188

Post by derefr »

js2 wrote: post #185
Scene_Cast2 wrote: post #176

Earlier quoted context omitted.

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.

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.

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

#189

Post by aaronblohowiak »

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?

Age, momentum; "network effects."
Post reply on HN