ALERT OpenSSL CVE-2014-0160 (heartbleed)

james · Apr 8, 2014

FYI

http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

jvangent100 · Apr 8, 2014

Yep major problem. I would also advice anyone that used openssl on their PBX AND had it open to internet to replace any certificates used on the box.

I checked my centos 6.5 box and it did have a vulnerable openssl version.

Just updated it using yum.
Even though this box is behind a firewall and doesn't have any ssl ports exposed to the internet, I am just replacing the apache and webmin certificates just to be sure.

wardmundy · Apr 8, 2014

~~Not sure how you did that since CentOS yum repo does not yet have a "safe" version (1.0.1g or later).~~

Correction: The "CentOS/Scientific Linux/RH Way" is to backport the fix to 1.0.1e. Version openssl-1.0.1e-16.el6_5.4.0.1 is now available, and it is an interim fix reportedly.

NOTE: To be perfectly safe, rerun the command below again later tonight until rpm -q openssl reports: 1.0.1e-16.el6_5.7. The repos still are being populated.

To test for vulnerable services:

Code:

lsof -n | grep ssl | grep DEL

To secure your system, run:

Code:

yum -y update openssl
service fail2ban restart
service sendmail restart
amportal kill
service mysqld stop
service httpd restart
service mysqld start
amportal start

wardmundy · Apr 8, 2014

The above fix ASSUMES that your server has not yet been compromised because you were running it behind a firewall with a WhiteList for secure access. If this is not the case, you've got a lot of extra work to do. See this post for some tips on what to do next.

jvangent100 · Apr 8, 2014

I recreated my private key and re-requested a new certificate from my internal CA just to be sure (and of course revoked the old cert at the CA).

In fact my box isn't offering 443 (for apache) and 9001 (for webmin) to external clients, but since replacing the key and getting a new cert isn't exactly hard work I did it anyway

The box definitely was vulnerable as I ran a python script against the server from another internal box.

That box was running Ubuntu and runs exim with ssl support, and yes that IS my smtp server open to the outside world so I definitely had to replace the cert on that box anyway.

Well it is patch Tuesday anyway, which is the day I normally apply Linux patches as well, so no biggie.

by the way openssl-1.0.1e-16.el6_5.7.x86_64 is the one I am running now.

Dan Lawrence · Apr 8, 2014

Does the same advice apply to the Scientific Linux OS base? I'm guessing it's the same concept with a different repository.

This Post indicates the fix is available on for SL.

Code:

$ yum update openssl
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* sl6x: 198.23.161.166
* sl6x-security: 198.23.161.166
Setting up Update Process
No Packages marked for Update

Is it possible the updates were automatically installed?

wardmundy · Apr 8, 2014

No. The update is not automatic. Same commands shown above for CentOS will now upgrade Scientific Linux installs as well.

Run the command rpm -q openssl. You should see the following after the update: 1.0.1e-16.el6_5.7

Dan Lawrence · Apr 8, 2014

Looks like I am at 1.0.1e-16.el6_5.4 which I believe is patched and safe?

Code:

$ rpm -q openssl
openssl-1.0.1e-16.el6_5.4.i686
$ yum -y update openssl
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* sl6x: 198.23.161.166
* sl6x-security: 198.23.161.166
Setting up Update Process
No Packages marked for Update

Looks like 5_4 is the most current at the SL repo...

Code:

$ yumdownloader openssl
Loaded plugins: fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
* sl6x: 198.23.161.166
* sl6x-security: 198.23.161.166
openssl-1.0.1e-16.el6_5.4.i686.rpm                                                      | 1.5 MB    00:00

awair · Apr 9, 2014

My understanding is that 5.4 is vulnerable and 5.4.0.1 is patched. Can someone more qualified confirm this?

At the time of writing, CentOS did not yet have a fixed version, but Karanbir Singh's posting to CentOS-announce says that they've produced an updated version of openssl (openssl-1.0.1e-16.el6_5.4.0.1, note the last four digits which are important) that has the exploitable TLS command disabled, and that can be safely applied as it will be overwritten by a fixed version when it is eventually released.

http://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it

I have just built a new 6.5 server (in the last month), which I believe means it is vulnerable, whereas 6.4 was not.

This issue did not affect the versions of openssl as shipped with Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6.4 and earlier. This issue does affect Red Hat Enterprise Linux 6.5, Red Hat Enterprise Virtualization Hypervisor 6.5, and Red Hat Storage 2.1, which provided openssl 1.0.1e.

https://access.redhat.com/security/cve/CVE-2014-0160

Ward, could you clarify/confirm your correction above:

Correction: The "CentOS/Scientific Linux/RH Way" is to backport the fix to 1.0.1e. Version openssl-1.0.1e-16.el6_5.4 is now available, and it is an interim fix reportedly.

Many thanks,

Hyksos · Apr 9, 2014

Yes, it's just a typo, 5.4 was the most recent vulnerable one, that's why 5.4.0.1 was made while waiting for 5.7.
But if you read the original post it clearly says 5.7 is the updated one already.
5.4.0.1 existed for a brief moment and was just misquoted by Ward as 5.4 because it's the most up to date _before_ this came down.

99.9% of people updating shouldn't care for such details as they got 5.7 by the time they updated or will get, by the time they do.
And some, should be most, people shouldn't have any affected services exposed publicly in the first place.
All your statements are right.

awair · Apr 9, 2014

Thanks for the clarification, I was a little confused...

My system reported 5.4 & Dan Lawrence's post (above) made me question whether this version was safe.

I've now updated to 5.7, which was available when I checked, it's just the hassle of all the other steps (certificates, revocation etc), which wouldn't be necessary if the 5.4 version was OK. A fun day ahead...

Hyksos · Apr 9, 2014

Not wanting to start debate there are a lot of ways to skin a cat but why do you have exposed vulnerable services and which?
Not trying to influence how you do things either, but it's interesting information for all actually.
You've setup SSL to serve the web interface and exposes that, for example?

wardmundy · Apr 9, 2014

This all should be academic for PIAF users. If your server is sitting behind a hardware-based firewall with NO Internet Port Exposure, there is zero risk. If you've opened ports and are using Travelin' Man WhiteList for safe access from specific IP addresses, there is zero risk. For everybody else, you're either NUTS or have a big wallet! Even if you work at this 24/7, you will NEVER be able to make your exposed system COMPLETELY SAFE because there will be a Zero Day Vulnerability (such as this one!) that bites you in the butt sooner or later.

5.4 should have been 5.4.0.1. My apologies. 5.7 is what you want/need.

awair · Apr 9, 2014

Ward, I agree with you that it 'should' be academic, but some of us like to tinker...

Hyksos, my PIAF server is also my mail server. My call usage is rarely more than a half-dozen calls a day, and those are predominantly between extensions. The alternative is to opt for a lesser PBX distro, with no security and add a mail-server to that.

My (inexperienced) view was to take the best, and 'break it, only a little bit'...

If you could indulge/educate me, to what extent might having standard mail ports open (25, 465, 993 etc) allow the PBX to be compromised?

Really appreciate all the effort that goes into PIAF. Many thanks again.

Hyksos · Apr 9, 2014

I'm not indulging or educating anyone

We're just chatting...
When the potential worst case scenario does not justify a more robust solution, there are "acceptable risks", always, they just vary.

to what extent might having standard mail ports open (25, 465, 993 etc) allow the PBX to be compromised?

To the full extent... like any exposed services is a potential full extent vulnerability.

People have a tendency to forget that if you're exposing things like a phone server which have access to your LAN, the potential compromise is your whole LAN which turns a vulnerability on this server into a complete LAN vulnerability, not good at all. You don't want to give somebody who has rooted your mail server unrestricted access to LAN and your windows workstation.
Whatever the segregation methods used, you never want public servers to have unrestricted access to your LAN.
And if the PBX needs to sit on the LAN the same server should not ALSO be sitting on the public Internet, accessible to every IP in the world.

But again everything is a risk assessment, you go crazy to protect multi million dollars Intellectual property... But if you don't even backup your mail server off site... You have a much greater risk of loss there then exposing an up to date Linux daemon to the Internet and not segregating it.
Measured risks.

You could run an hypervisor like ESX or proxmox and have virtualized servers, all segregated and with firewall rules preventing potentially vulnerable public servers from accessing the rest of your network.

But hey, some have only one server, running windows, exposed to the Internet and it's also their Domain controller and it does everything public and everything LAN but their potential worst case scenario is a couple hundred bucks of technicians reinstalling _everything_ in the shop and reloading backups. Paying big money to minimize this risk is dumb.
Many ways to skin a cat.

jvangent100 · Apr 9, 2014

It is simple really, I firmly believe any website (such as in this case the freepbx admin console) that requires a password should be running on port 443 with an ssl certificate. Even if the actual service isn't exposed to the internet. So even on the local lan, unless of course you like your password to be sniffed by some handy employee that is on the same lan.

Having said that, even if your server isn't exposed to the internet and is vulnerable to this particular gem, patching it still remains vital, as that same employee could now easily run a python script to see the memory of httpd if not patched, including your private key, which invalidates the whole purpose of ssl in the first place.

And yes, putting such an interface onto the public internet is an awfully bad idea. If you need to administer the server remotely use a secure vpn connection into your lan.

In my case, the only ports open on PIAF are 5060 and media ports. And yes I happen to run a single Windows server at home, which is also a dc, and runs hyper-v, which in turn runs the rest. This setup is as secure as they come. The hyper-v box as such isn't exposed to the internet in any way, only a few virtual servers are exposed in a way that only necessary ports are accessible. 443 for webmail, 25 for smtp, and already discussed 5060 and media ports for Voip. All of these servers have their own firewall in turn only exposing relevant ports to local lan clients.

It certainly can be done securely. Of course just not exposing anything to the internet isn't an option, as that way your webmail and mailflow won't work, neither will your PBX. I personally have not opted to actually deploy the DMZ approach at home (at work is of course a different story), and quite frankly if you stay on top of stuff like this, the risks are minimal.

Dan Lawrence · Apr 9, 2014

For the record, I am running PiaF green 3.0.6.5 on a rentbox virtual server. I am running traveling man 3 with only a single static IP address allowed in. I am confident I have no exposure to an attack via Heartbleed.

That being said, it would be foolish to ignore a known attack vector so I do want to make sure I am updated to the latest properly patched version of openssl.

This must be a customization that rentbox does, but it really appears that security updates are happening automatically via YUM. For example, my PiaF box sent me the below email at 4:30am today.

Code:

--------------------
YUM - security
--------------------
 
================================================================================
Package            Arch      Version                Repository          Size
================================================================================
Updating:
openssl            i686      1.0.1e-16.el6_5.7      sl6x-security      1.5 M
openssl-devel      i686      1.0.1e-16.el6_5.7      sl6x-security      1.2 M
openssl-perl        i686      1.0.1e-16.el6_5.7      sl6x-security      48 k
openssl-static      i686      1.0.1e-16.el6_5.7      sl6x-security      1.0 M
 
Transaction Summary
================================================================================
Upgrade      4 Package(s)
 
Total download size: 3.7 M
 
Updated:
  openssl.i686 0:1.0.1e-16.el6_5.7      openssl-devel.i686 0:1.0.1e-16.el6_5.7
  openssl-perl.i686 0:1.0.1e-16.el6_5.7 openssl-static.i686 0:1.0.1e-16.el6_5.7

Running the same commands that I ran yesterday show openssl has been updated:

Code:

$ rpm -q openssl
openssl-1.0.1e-16.el6_5.7.i686
$ yum -y update openssl
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* sl6x: 198.23.161.166
* sl6x-security: 198.23.161.166
Setting up Update Process
No Packages marked for Update

I guess the takeaway here is there are configurations that are automatically applying security updates with zero user intervention.

wardmundy · Apr 10, 2014

For those on the Raspberry Pi or Beaglebone Black platform, issue the following commands.

Do NOT overwrite the MOTD file when prompted whether to do so! Correct answer: N

Code:

apt-get update
apt-get -y upgrade
reboot

visionlogic · Apr 11, 2014

wardmundy said:
For those on the Raspberry Pi or Beaglebone Black platform, issue the following commands.

Do NOT overwrite the MOTD file when prompted whether to do so! Correct answer: N

Code:

apt-get update apt-get upgrade reboot

Thanks for the instructions Ward. I just upgraded my RasPi and all appeared to go smoothly. However, during the process I did not receive any prompt regarding an overwrite of the MOTD file. Should that be a concern? The box appears to be operating normally.

wardmundy · Apr 11, 2014

That message may only appear on the BeagleBone Black. I couldn't remember which. Thanks.

ALERT OpenSSL CVE-2014-0160 (heartbleed)

Guru

Member

Nerd Uno

Nerd Uno

Member

Member

Nerd Uno

Member

Member

Guru

Member

Guru

Nerd Uno

Member

Guru

Member

Member

Nerd Uno

Guru? Nope

Nerd Uno

Forum statistics