Update your OpenSSL now!

interfasys

interfasys

Verified User
Joined
Oct 31, 2003
Messages
1,816
Location
Switzerland
I wasn't going to post anything about it since this is a base library, but the heartbleed vulnerability is very serious and dangerous.

Read more about it on heartbleed.com

Scanning an unpatched server reveals passwords, and all sorts of private information.

Fix:
  • Update your distribution's OpenSSL
  • Find all services which rely on OpenSSL
  • Restart them
  • Generate new private keys for all your certificates
  • Generate and install new certificates
  • Revoke all old certificates
  • Change all passwords
  • Invalidate all session keys and cookies
  • Write a nice email to all your customers, asking them to reset their passwords
 
Last edited:
I'm currently testing my update before rolling it out.
cd /usr/src
wget http://www.openssl.org/source/openssl-1.0.1g.tar.gz
tar -xvzf openssl-1.0.1g.tar.gz
cd openssl-1.0.1g

./config --prefix=/usr no-threads shared
make
make test
make install

After updating openSSL, we need to update DirectAdmin
cd /usr/local/direcctadmin/custombuild
./build clean
./build update
./build apache
./build php d
./build exim
./build dovecot
 
Last edited:
You don't need to update DirectAdmin if you have the newest version, however you should restart DirectAdmin after you have patched OpenSSL. By the way, the OpenSSL update is already available for CentOS/RedHat:

http://www.mail-archive.com/[email protected]/msg08242.html
and
https://rhn.redhat.com/errata/RHSA-2014-0376.html

So if you run CentOS, I would recommend doing it like this:

Code: 
yum update
service httpd restart
service exim restart
service dovecot restart
service sshd restart
service proftpd restart
service directadmin restart

Please make a comment if you think I have forgot some services that uses OpenSSL and wich need to be restarted, here is a quote from RedHat:

For the update to take effect, all services linked to the OpenSSL library (such as httpd and other SSL-enabled services) must be restarted or the system rebooted.
Click to expand...

Edit: Please see this great way to test wich services still using the old OpenSSL libraries: http://www.webhostingtalk.com/showpost.php?p=9076001&postcount=35
 
Last edited:
Updated the OP with a generic how-to:
Fix:
  • Update your distribution's OpenSSL
  • Find all services which rely on OpenSSL
  • Restart them
  • Generate new private keys for all your certificates
  • Generate and install new certificates
  • Revoke all old certificates
  • Change all passwords
  • Invalidate all session keys and cookies
 
interfasys said:
Please note that this test site is unreliable. It's best to use your own scripts to scan your servers.
Click to expand...

Correct... From any OpenSSL 1.x system you can make this call:

Code: 
openssl s_client -connect hostname.com:443 *-tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

...to test with.

EDIT: MAY NOT WORK RELIABLY, SEE POST #15
 
Last edited:
Just a question... it says the flaw will be fixed with openssl 1.0.1g.
But I just update all Centos servers, they have 1.0.1e. G comes after E in the alphabet. Does this mean Centos have fixed it in the "e" release? Or is the fix still to come in Centos?
 
Richard G said:
Just a question... it says the flaw will be fixed with openssl 1.0.1g.
But I just update all Centos servers, they have 1.0.1e. G comes after E in the alphabet. Does this mean Centos have fixed it in the "e" release? Or is the fix still to come in Centos?
Click to expand...

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable

If you are on "G" then you'd be OK
 
scrupul0us said:
Correct... From any OpenSSL 1.x system you can make this call:

Code: 
openssl s_client -connect hostname.com:443 *-tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

...to test with.
Click to expand...
No, that test does not work because it can't know which version of OpenSSL the server is using.
Run the command against a patched server and you'll see.
 
Richard G said:
Just a question... it says the flaw will be fixed with openssl 1.0.1g.
But I just update all Centos servers, they have 1.0.1e. G comes after E in the alphabet. Does this mean Centos have fixed it in the "e" release? Or is the fix still to come in Centos?
Click to expand...
What some distros do is to patch the vulnerability only, without upgrading the whole library, so you'll keep the same version number. A library update could potentially break many things.
 
@interfasys: I was thinking that way too, because I've seen Centos fixing things like that before, just wanted to be sure. I'm satisfied now. Thanks for the confirmation.
 
I am using this command http://www.webhostingtalk.com/showpost.php?p=9076001&postcount=35 on my servers to see if some services still use the old OpenSSL libraries:

Code: 
lsof -n | grep ssl | grep DEL

On a few servers nothing came out, however on two of my servers I get results like this:

Code: 
[root@server~]# lsof -n | grep ssl | grep DEL
dsm_sa_da  9002      root  DEL       REG                8,2             2632274 /usr/lib64/libssl.so.1.0.1e
dsm_sa_da  9075      root  DEL       REG                8,2             2632274 /usr/lib64/libssl.so.1.0.1e

I found that strange, because I did restart DirectAdmin after I upgraded OpenSSL. So, it is safe to kill those pid's? I could not find those pid numbers in "Service Monitor", so I am confused about them. I did try to search on Google after "dsm_sa_da", but it did not give any relevant results.

Edit: In addition to previous restart of DirectAdmin, I now just did a full stop and start of DirectAdmin, but still it shows those dsm_sa_da pid's on the server. Does anybody know what those dsm_sa_da pid's is, and is it safe to kill them?
 
Last edited:
You must log in or register to reply here.
Back
Top