Update your OpenSSL now!

@toml, than you very much. I thought it was a DirectAdmin service because of the naming, i did this to restart all the Dell services:

Code: 
srvadmin-services.sh stop
srvadmin-services.sh start

Now I only have one server that still show result when checking for services using old OpenSSL, it is a DirectAdmin pid, and I can see the pid in the "Service monitor", however I am unable to kill it and/or remove it:

First I check my server:
Code: 
[root@server~]# lsof -n | grep ssl | grep DEL
directadm  7660      root  DEL       REG                8,2               2705316 /usr/lib64/libssl.so.1.0.1e

Then I kill the pid:
Code: 
[root@server~]# kill 7660

Then I check my server again, but the pid is still there, and is still using old OpenSSL:
Code: 
[root@server~]# lsof -n | grep ssl | grep DEL
directadm  7660      root  DEL       REG                8,2               2705316 /usr/lib64/libssl.so.1.0.1e

Also it does not help to stop/restart DirectAdmin. What can I do to get red of the above pid/problem?
 
@toml, thanks a lot! kill -9 fixed it, and finally none of my servers is using the old openssl version anymore:

Code: 
[root@server ~]# lsof -n | grep ssl | grep DEL
directadm  7660      root  DEL       REG                8,2               2705316 /usr/lib64/libssl.so.1.0.1e
[root@server~]# kill -9 7660
[root@server~]# lsof -n | grep ssl | grep DEL
[root@server~]#

I guess the next thing is to spend the night buying/renew all my servers ssl certificates. Not happy about that, because I recently renewed them all by two more years. But it seems to be needed, so I will do it. :)
 
Hi,

I'm just a noob so it took me a lot of reading. I accidentally, upon finding out about this openssl bug, updated openssh. I didn't really pay close attention but it did stuff. :-)

After finding out that I had done the wrong update I got confused since I knew the update was out and yet I was not getting any openssl update.

Anyhow, I finally got enough reading down to feel confident I've done all that I needed on the openssl bug for now.

I just wanted relay some info that helped me to get a grasp of the situation. Due to the standard RH/Centos procedures, and me looking for openssl "g" revision that is widely discussed as the fix, it was kind of a head scratcher for a bit..

RE CentOS 6.5: https://www.centos.org/forums/viewtopic.php?f=9&t=45814#p194518
rpm -q openssl` and it reports version 1.0.1e and less than 1.0.1e-16.el6_5.4.0.1 then you are currently vulnerable to this problem. If it reports 1.0.1e-16.el6_5.4.0.1.centos then you have the temporary version issued before Redhat issued their official fix. If you have 1.0.1e-16.el6_5.7 or higher then you have the official fixed version."
Click to expand...

My conclusion about OpenSSH update being responsible came from seeing:

# rpm -q openssl
openssl-1.0.1e-16.el6_5.7.x86_64

..on my box. Thank goodness! Now I can close some of the multitude of browser tabs and windows and quit shuffling between them as I open more windows.. lol
 
just NOW did yum update and it offered version e so I am not sure whats going on.

edit: I missed that rh/cent would backport the patch onto version e so I may e ok
 
Last edited:
two issues:

when I do a yum update then restart the httpd service openssl is updated to OpenSSL 1.0.1e-fips, not 1.0.1g (I thought all version < 1.0.1g are vulnerable??)

the second issue is even openssl is updated to 1.0.1, under curl the ssl version is still openssl 1.0.0??
 
Last edited:
@redjersey

try this:

rpm -qa openssl\*

if you see this:

openssl-devel-1.0.1e-16.el6_5.7.x86_64
openssl-1.0.1e-16.el6_5.7.x86_64

.. then you have the latest redhat patch -- note the key part is the _5.7

Then just [strike]restart[/strike] kill|stop -> start openssl and all ssl dependent services or reboot
 
Last edited:
when I run:

# rpm -qa openssl\*
openssl-devel-1.0.1e-16.el6_5.7.x86_64
openssl-1.0.1e-16.el6_5.7.x86_64

I do get the exact same lines, I also did a reboot, but my phpinfo is still showing curl ssl is running openssl 1.0.0 and openssl-1.0.1e

so is it mean that the latest patch are added to both 1.0.0 and 1.0.1e?
 
The SSL is good from what I read... However I am unqualified to instruct you myself on the httpd. I did read tons about this bug and recall many getting advice that they needed to recompile Apache. I guess there is something (mod_ssl?) of the installed openssl which Apache relies on when when it's installed. If that makes any sense.

I think much of the people who could answer you more authoritatively are working on their servers in light of this bug.

Let me see if I can dig up some of the links I have on this and will edit them in here in a minute.

Maybe this: "Did you just restart apache or did you kill it completely and restart it? A graceful restart doesn't kill it completely" (duh, guess that's not related since you said you rebooted..)

RE: http://www.webhostingtalk.com/showthread.php?t=1364373 post #21

..sorry I don't seem to have much more than the one link to WHT ~post 12 or so someone was commenting about recompile for apache but nobody in that conversation indicates recompile is required.
 
Last edited:
I am from Vietnam where I have not updated with YUM yet.
Follow midas's guide. my server is safe now.
thanks
 
saosangmo,

If I understand you correctly, affected redhat/centos and the openssl-1.0.1g.tar.gz AFAIK isn't the best approach.

Official centos/redhat updates patch the 1.0.1e library instead of updating the 1.0.1e library to 1.0.1g.

I guess it will break the ability for YUM to update your openssl and anything that uses openssl, at least..
 
I had to rebuild php because header file and library version not matched.
Just for your information.
 
FreeBSD users should be unaffected as they use OpenSSL 0.9.8y built-in.

Just in case, if you eventually compiled OpenSSL from ports (usually people don't do that), check your ports tree for it and see if it's up to date..
 
Spook said:
The SSL is good from what I read... However I am unqualified to instruct you myself on the httpd. I did read tons about this bug and recall many getting advice that they needed to recompile Apache. I guess there is something (mod_ssl?) of the installed openssl which Apache relies on when when it's installed. If that makes any sense.

I think much of the people who could answer you more authoritatively are working on their servers in light of this bug.

Let me see if I can dig up some of the links I have on this and will edit them in here in a minute.

Maybe this: "Did you just restart apache or did you kill it completely and restart it? A graceful restart doesn't kill it completely" (duh, guess that's not related since you said you rebooted..)

RE: http://www.webhostingtalk.com/showthread.php?t=1364373 post #21

..sorry I don't seem to have much more than the one link to WHT ~post 12 or so someone was commenting about recompile for apache but nobody in that conversation indicates recompile is required.
Click to expand...

yes I did, I did restarted the httpd, I have also rebooted my server just in case.
but under curl the ssl version is still showing openssl 1.0.0

I have tried http://filippo.io/Heartbleed with mydomain.com:443 which says my server seems ok, but I just don't know how to fix that curl issue.

#curl -V
curl 7.36.0 (x86_64-unknown-linux-gnu) libcurl/7.36.0 OpenSSL/1.0.0 zlib/1.2.3 libidn/1.18
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz

Update: not sure why but I had to build the curl again (already did it last nite, not working)
./build curl
./build php d

now it's showing 1.0.1e
 
Last edited:
Hi.
after distribution update!

If i check the SSL Connections on Port 443 on Debian 7 and centos 6,5 (Both 64 bit) everything is OK.
If i check the port 2222 on both boxes
the centos box say everthing is ok, but the debian 7 is vulnerable
 
i have try to reinstall DA with the latest prerelease but same message on a debian 7 64bit OS when i check the port 2222
Server is vulnerable, please upgrade software ASAP
 
You must log in or register to reply here.
Back
Top