I'm really surprised no one has mentioned this here yet...
FYI,
- - ferg
RHEL and CentOS both have patches out as of a couple hours
ago, so run those updates! CentOS' mirrors do not all have
it yet, so if you are updating, make sure you get the
1.0.1e-16.el6_5.7 version and not older.
David
OK, now... it's far too late for April Fool's. 
That's scary as heck. Guess I know what the first order of business will be tomorrow...
- Pete
Not just run the updates -- all private keys should be changed too, on the assumption that they've been compromised already. THAT is going to be the crappy part of this.
- Pete
It's bad. I decided to test my servers after updating them. Took me
about 3 hours to write a working implementation of this attack without
any prior knowledge of TLS internals. It's easy to do, pretty much
impossible to detect, and it's going to spread quickly. Shut down your
https sites and any other TLS services until you've updated OpenSSL,
then think about changing your private keys.
- Max
I'm really surprised no one has mentioned this here yet...
we're all to damned busy updating and generating keys
you might like (thanks smb, or was it sra)
openssl s_client -connect google\.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe
randy, who is almost through
That just tells you whether the heartbeat extension is supported.
Google servers are not vulnerable to this attack.
- Max
Don't forget to restart every daemon that was using the old library as
well, or just reboot.
Randy Bush <randy@psg.com> writes:
you might like (thanks smb, or was it sra)
openssl s_client -connect google\.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe
protip: you have to run this from a device that actually is running
1.0.x, i.e. supports the heartbeat extension. your desktop mac
(running 0.9.8y if you're running mavericks and haven't stomped on it
via ports; homebrew is a keg only install) WILL NOT SUFFICE and will
just sit there quietly until the http server times out (60 seconds in
my case) and then echo "safe" even when you're not.
-r
Just as a data point, I checked the servers I run and it's a good thing I didn't reflexively update them first.
On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have the vulnerability, but the
ones queued up for update do. I assume that redhat will get the patched version soon but be careful!
Mike
The updated CentOS openssl binaries haven't patched the underlying bug, but
they have disabled the heartbeat functionality. By doing so, they've
disabled the attack vector. Once upstream releases a fix, they will
re-enable the heartbeat function with the working patch.
And yes, don't forget to restart any linked services after updating.
-richard
For testing, I've had good luck with
https://github.com/titanous/heartbleeder and
https://gist.github.com/takeshixx/10107280
Both are mostly platform-independent, so they should be able to work even
if you don't have a modern OpenSSL to test with.
Cheers and good luck (you're going to need it),
jof
1.0.1 was not deployed until RHEL 6.5. RedHat released patches
for RHEL last night, and CentOS followed suit a few minutes
later.
Lots of tools available. I'm with ferg, surprised more haven't been mentioned here.
Tools to check for the bug:
• on your own box: https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py
• online: http://filippo.io/Heartbleed/ (use carefully as they might log what you check)
• online: http://possible.lv/tools/hb/
• offline: https://github.com/tdussa/heartbleed-masstest <--- Tobias Dussa, also Takes a CSV file with host names for input and ports as parameter
• offline: http://s3.jspenguin.org/ssltest.py
• offline: https://github.com/titanous/heartbleeder
List of vulnerable Linux distributions: <http://www.circl.lu/pub/tr-21/>.
Anyone have any more?
According to the changelog it cvs is fixed now.
$ rpm -qa|grep openssl
openssl-1.0.1e-16.el6_5.7.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64
Tue Apr 8 12:17:25 EDT 2014
Z643357:~
$ rpm -q --changelog openssl | less
* Mon Apr 07 2014 Tomás( Mráz <tmraz@redhat.com> 1.0.1e-16.7
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension
Here's mine, written in Go:
http://code.google.com/p/mxk/source/browse/go1/tlshb/
To build the binary, install Mercurial, install Go (golang.org), set
GOPATH to some empty directory, then run:
go get code.google.com/p/mxk/go1/tlshb
- Max
If we would front our HTTPS services with a (OpenSSL vulnerable)
load-balancer that does the SSL work and we just use HTTP to the service,
will that mitigate information loss that's possible with this exploit? Or
will the OpenSSL code on the load-balancer also store or "cache" content?
Frank
You can still potentially access all the same information since it all goes through the load balancer. Interesting bits of info are things like Cookie: headers being sent by clients and sitting in a buffer. Try one of the testing tools mentioned and see if you can see any info from other clients. It's almost like having remote tcpdump on the web server - you can copy down the in-memory process image.
-Laszlo
Once upon a time, Frank Bulk <frnkblk@iname.com> said:
If we would front our HTTPS services with a (OpenSSL vulnerable)
load-balancer that does the SSL work and we just use HTTP to the service,
will that mitigate information loss that's possible with this exploit? Or
will the OpenSSL code on the load-balancer also store or "cache" content?
One of the biggest risks that could be exposed in this particular case
is the SSL private key. If your front end is handling SSL with OpenSSL,
it'll have the key, and that is vulnerable.
Hi,
I was wondering why most of my secure services didn't show up as
vulnerable...