If one were using ASLR would this have mostly mitigated this? (I just rebuilt without the heartbeat extension but I'm curious). Also how exploitable is this?
I don't think ASLR helps here one single bit.
OpenSSL Security Advisory: TLS heartbeat read overrun
61–70 of 88 posts
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#62Earlier quoted context omitted.
Segmenting my network isn't an option when "my network" involves machines on multiple continents. I avoided ssh because sshd is an effectively unauditable mess, and breaks the "transient network glitches don't kill quiescent connections" assumption.
How do transient network glitches kill the connection? I'm not completely familiar with the ssh wire protocol, but to my knowledge TCP is largely responsible for ensuring the reliability of the virtual circuit even in the event of a transient lower-layer failure.
ssh frequently uses either application-level or TCP-level keepalives. But it doesn't have to; you can just turn off ssh keepalives and your quiescent connections will survive network outages.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#63Go C!
Hope everyone had forward secrecy on by now.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#64"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=...
Ouch, pretty basic lack of bounds checking.
Even though the code got better with this fix I still wouldn't accept code that looks like this in a review. Why are 1, 2, 3, 16 not defines? What's up with the code duplication between files? Where are the unit-tests?
I'm starting to feel that a lot of software that has been around for 10+ years and is commonly used does not live up to current best practices regarding writing good system-level software.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#65Anybody knows if the bug can be triggered in OpenSSH (I believe it uses the same lib?)
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#66"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!
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#67Check for the extension: $ echo -e "quit\n" | openssl s_client -connect google.com:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' TLS server extension "heartbeat" (id=15), len=1 This doesn't tell you that the server uses OpenSSL, or that it is vulnerable, simply that it supports the extension.
At least in my Bash (4.2.25(1)), there seems to be a difference between "2>&1|" and "2>&1 |" – the latter works as expected, whereas the former doesn’t give any output.
$ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'
$ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1 | grep 'TLS server extension "heartbeat" (id=15), len=1'
TLS server extension "heartbeat" (id=15), len=1
$
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#68If your site is protected by CloudFlare (like HN is), you are automatically protected from this vulnerability (see: http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerab... ).
You are protected now . But you were not before, so if any attacker figured this out before the public disclosure then you have [possibly] already been attacked and compromised.
Not entirely correct, as the blog post states:
> We fixed this vulnerability last week before it was made public.
Although there's still the other 103 weeks this was vulnerable to worry about.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#69Anybody knows if the bug can be triggered in OpenSSH (I believe it uses the same lib?)
Most likely no since SSH is a different protocol than TLS.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#70Earlier quoted context omitted.
All reasonable certificate authorities will — at no cost — revoke your existing certificate and issue you a new certificate with the same expiration date as your old certificate. You'd just need to send the CA a new certificate signing request created from a newly-generated RSA key pair. If your CA wants you to buy a new certificate to recover from a key compromise, your CA is taking you for a ride, and you should fi…
I think startssl requires $$$$ to revoke and/or reissue those "free" certs before they expire :-/
Is there another good CA that doesn't charge $$$ for both issuing and revocations?