Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory: TLS heartbeat read overrun

openssl.org

Post reply on HN
Print view View original

81–88 of 88 posts

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#81

Post by Jare »

iso8859-1 wrote: post #18
nly wrote: post #5

"Don't roll your own parsers" should really be up there with "Don't roll your own crypto". This advisory is scant on details, but this extension protocol[0] neither looks complex nor beyond mechanical code generation to me. Just simple enough to be dangerous. And it's pretty new, so this must be recently authored vulnerable code. [0] http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04

Here's the commit for the fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

I felt much better about having a fix before I looked at the actual code. It is functionally secure (looks right to me and thousands of others by now), but the way it is written would guarantee you an instant fail in an exam or interview.

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#82

Post by dijit »

midas007 wrote: post #47

If you'd like to update the keg-only OpenSSL brew on osx, and dont care for legacy and crap: ( export CONFIGURE_OPTS='no-hw no-rdrand \ no-sctp no-md4 no-mdc2 no-rc4 no-fips no-engine'; \ brew install https://gist.github.com/steakknife/8228264/raw/openssl.rb ) Beware, that by default on osx/ios, pretty much everything links to sketchy CommonCrypto or a crusty, quasi-deprecated 0.9.8.

of course, anyone using 0.9.8 is fine.

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#83

Post by danielweber »

zurn wrote: post #66
nly wrote: post #5

"Don't roll your own parsers" should really be up there with "Don't roll your own crypto". This advisory is scant on details, but this extension protocol[0] neither looks complex nor beyond mechanical code generation to me. Just simple enough to be dangerous. And it's pretty new, so this must be recently authored vulnerable code. [0] http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04

> "Don't roll your own parsers" should really be up there with "Don't roll your own crypto". .. and if you do, don't do it in a highly memory-unsafe language. Espcially when it's for a security critical piece of central internet infrastructure!

How do the Ruby-YAML and Python-Pickle vulnerabilities get cataloged?

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#84

Post by hackinthebochs »

nly wrote: post #5

"Don't roll your own parsers" should really be up there with "Don't roll your own crypto". This advisory is scant on details, but this extension protocol[0] neither looks complex nor beyond mechanical code generation to me. Just simple enough to be dangerous. And it's pretty new, so this must be recently authored vulnerable code. [0] http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04

I've been thinking along these lines for a long time now, that parsing is such a critical activity that we should treat it with far more reverence than we do. Ideally, we would define languages to describe the format of the data that we want to parse (something like a BNF perhaps), and the OS/environment would parse it and populate variables/provide a dictionary in response. Ensuring that the input to your algorithm is exactly as expected is such a critical task that no one should ever be doing it manually.

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#85

Post by dhimes »

simias wrote: post #78
iso8859-1 wrote: post #18

Earlier quoted context omitted.

Here's the commit for the fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

if (1 + 2 + 16 > s->s3->rrec.length) if (1 + 2 + payload + 16 > s->s3->rrec.length) Come on. At least use a macro or something. This always makes me cringe during code reviews.

Yep, and no braces after the 'if' statement in the patch. Even after the previous ssl vuln (I thought it was gnutls- struggling to find the relevant hn discussion) was caused by an omission of braces after the 'if' statement.

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#86

Post by saurik »

dhimes wrote: post #85
simias wrote: post #78

Earlier quoted context omitted.

if (1 + 2 + 16 > s->s3->rrec.length) if (1 + 2 + payload + 16 > s->s3->rrec.length) Come on. At least use a macro or something. This always makes me cringe during code reviews.

Yep, and no braces after the 'if' statement in the patch. Even after the previous ssl vuln (I thought it was gnutls- struggling to find the relevant hn discussion) was caused by an omission of braces after the 'if' statement.

You are thinking of "goto fail", a bug in Apple's Security framework. I would not claim that was "caused" by a lack of braces: even having the braces, that bug--in addition to a wide class of similar bugs--is still quite possible, even if in a few models of how the bug was caused it becomes slightly less likely. The best place to lay blame for that kind of error is a stubborn insistence that error handling should involve boilerplate return value checks strewn throughout the code, with no attempt at abstraction or structure: it leads to numerous potential mistakes. Please read the various discussions attached to this article that made this claim:

https://news.ycombinator.com/item?id=7318039

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#87

Post by dhimes »

saurik wrote: post #86
dhimes wrote: post #85

Earlier quoted context omitted.

Yep, and no braces after the 'if' statement in the patch. Even after the previous ssl vuln (I thought it was gnutls- struggling to find the relevant hn discussion) was caused by an omission of braces after the 'if' statement.

You are thinking of "goto fail", a bug in Apple's Security framework. I would not claim that was "caused" by a lack of braces: even having the braces, that bug--in addition to a wide class of similar bugs--is still quite possible, even if in a few models of how the bug was caused it becomes slightly less likely. The best place to lay blame for that kind of error is a stubborn insistence that error handling should inv…

Yes, that is exactly what I was thinking of. Thanks for the link. The discussion I was recalling is here

https://news.ycombinator.com/item?id=7282005

but the thread is a lot heftier now.

Re: OpenSSL Security Advisory: TLS heartbeat read overrun

#88

Post by tripzilch »

otterley wrote: post #54
cperciva wrote: post #45

Earlier quoted context omitted.

spiped should be irrelevant here. But there are a lot of people using PKI where they could be using PSK.

Who, exactly? Distributing shared secrets securely is a non-trivial exercise.

You mean like wifi-passwords? :) Everybody seems to manage distributing those just fine?
Post reply on HN