OpenSSL leaked see http://heartbleed.com/

Virtualmin
#1

Hi all

Open SSL seems to have a serious bug:

http://heartbleed.com/

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users.

If this is true, all our SSL certs are worthless, currently!

openssl version

on an up-to-date Centos Virtualmin system

gave me:

OpenSSL 1.0.1e-fips 11 Feb 2013

which the article above confirms being UNSAFE.

Unfortunately

yum update openssl

returns:

Setting up Update Process
No Packages marked for Update

The article above also suggests that OpenSSL 1.0.1.g would be safe.

Could someone please look into this and (hopefully) provide a fix. Currently everyone using Virtualmin is at risk having their private keys or sensible data leaked/stolen. They say attackers leave no trace!

It clearly has nothing to do with Virtualmin itself, it’s a bug in OpenSSL, however I believe it effects the entire community running Virtualmin, therefore I am posting it here.

#2

Howdy,

It looks like RHEL/CentOS is in the process of publishing a fix for that… it should be available shortly, if it’s nor already. There’s additional information available here:

https://www.centos.org/forums/viewtopic.php?f=9&t=45814

A fix already appears to be in the Debian and Ubuntu repositories, and can be obtained using “apt-get update && apt-get upgrade”.

-Eric

#3

Hello,

In that regard, I found something weird. I’m not sure it’s a bug, maybe just a confusion, and I can’t test it again to tell right from wrong.

So, I’m just reporting it, it’s not a support request, okay :slight_smile:

Here’s the thing.
This morning I saw the news about heartbleed, so I hurriedly opened my server’s virtualmin (debian wheezy) and ran the built-in virtualmin update process, since, as expected, there was a mention of an update. First OpenSSL, and then, there were 3 additional packages in which I read SSL, I let them get installed, and since then, there has been no new mention of anything to install.

Later on, I found this neat website, allowing to test ourselves against this openSSL leak :
http://filippo.io/Heartbleed

I ran the test, just to feel comforted.
" VULNERABLE ! ", said the page !

Me : O_o

I didn’t bother for careful testing, I simply rebooted my server at once, and, a minute later, the test told there was no more vulnerability.

This is as if the update manager didn’t bother to restart the service after updating it, for heaven’s sake ?!?
(I insist : this is not a call for help, my server is secure again, I’m cool.)

Maybe that’s a bug, maybe not, no idea. But, maybe if it’s an issue with virtualmin and it’s important to report it, so here I stand, haha.

Have a good day, everyone !

#4

Red Hat have fixed it now:

https://rhn.redhat.com/errata/RHSA-2014-0376.html

and a simple

yum update

does the trick. However, you need to restart the relevant services or reboot the server:

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.

#5

Howdy,

Hmm, I saw the same behavior on my own Ubuntu systems… just performing the update only reloaded the config, it didn’t restart Apache.

It appears that you may need to either restart Apache, or restart the server, after performing the update.

Performing that restart would actually be done within the distribution’s Apache package… so Ubuntu/Debian might need to tweak that package. Though manually restarting Apache seems to do the trick as well :slight_smile:

-Eric

#6

A user in my hoster’s forum posted this command that you can use to check for candidates that are still using the old (deleted/replaced) library file, by listing processes that hold the old file open:

lsof | grep -i 'del' | grep 'ssl'

In any case, if possible a reboot of the server is preferred, since then you can be sure not to have overlooked anything.

@Eric: What about Webmin itself? Does its miniserv use the system’s SSL library, and is thus safe when OpenSSL is updated? Or does it use an SSL library of its own?

#7

After talking to Jamie, it sounds like it would be a good idea to restart the Webmin process. He indicated that it does indeed use openssl.

I suspect the same would also be true for Dovecot and Postfix. I believe I recall seeing OpenSSH being automatically restarted, though it can’t hurt to manually restart it just to be sure.

However, the other option is to just reboot, as Locutus mentioned :slight_smile:

-Eric

#8

Yeah, so Debian released updated update packages, this time including restarting instructions for the services relying on openSSL. They must have been in a serious state of panicked frenzy to forget restarting requests in their first version ^^

#9

It seems that all our 64-bit OS dedicated servers got updated agains the heartbleed vulnerability, however nothing is happening on any of our 32-bit Couldmin guest systems:

root@my:/etc/yum.repos.d#
yum update
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile

  • base: mirror.stanford.edu
    base | 3.7 kB 00:00
    Setting up Update Process
    No Packages marked for Update

This is quite urgent matter for us, so should be file an issue or wait till some viable solution will be offered here.

#10

Here is an output from firing up “yum info openssl” command on one of our vulnerable VPSs:

root@my:/etc/yum.repos.d# yum info openssl Loaded plugins: fastestmirror, presto Loading mirror speeds from cached hostfile * base: mirror.stanford.edu Installed Packages Name : openssl Arch : i686 Version : 1.0.1e Release : 15.el6 Size : 3.9 M Repo : installed From repo : base Summary : A general purpose cryptography library with TLS implementation URL : http://www.openssl.org/ License : OpenSSL Description : The OpenSSL toolkit provides support for secure communications between : machines. OpenSSL includes a certificate management tool and shared : libraries which provide various cryptographic algorithms and : protocols.
#11

Please everybody note we’ve found the solution. Turns out we had disabled Updates in CentOS-Base.repo file. After enabling the Updates repository and running ‘yum updates’ the issue got resolved. Thanks!

#12