ALERT OpenSSL CVE-2014-0160 (heartbleed)

Discussion in 'Bug Reporting and Fixes' started by james, Apr 8, 2014.

  1. james

    james Guru

    Joined:
    Oct 18, 2007
    Messages:
    375
    Likes Received:
    38
  2. jvangent100

    jvangent100 Member

    Joined:
    Jan 21, 2008
    Messages:
    47
    Likes Received:
    1
    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.
     
  3. wardmundy

    wardmundy Nerd Uno

    Joined:
    Oct 12, 2007
    Messages:
    14,413
    Likes Received:
    2,448
    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
    
     
  4. wardmundy

    wardmundy Nerd Uno

    Joined:
    Oct 12, 2007
    Messages:
    14,413
    Likes Received:
    2,448
    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.
     
  5. jvangent100

    jvangent100 Member

    Joined:
    Jan 21, 2008
    Messages:
    47
    Likes Received:
    1
    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.
     
  6. Dan Lawrence

    Dan Lawrence Member

    Joined:
    Jan 4, 2008
    Messages:
    44
    Likes Received:
    7
    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?
     
  7. wardmundy

    wardmundy Nerd Uno

    Joined:
    Oct 12, 2007
    Messages:
    14,413
    Likes Received:
    2,448
    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
     
  8. Dan Lawrence

    Dan Lawrence Member

    Joined:
    Jan 4, 2008
    Messages:
    44
    Likes Received:
    7
    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
     
  9. awair

    awair Member

    Joined:
    Mar 10, 2009
    Messages:
    86
    Likes Received:
    4
    My understanding is that 5.4 is vulnerable and 5.4.0.1 is patched. Can someone more qualified confirm this?

    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.

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

    Ward, could you clarify/confirm your correction above:
    Many thanks,
     
    Hyksos likes this.
  10. Hyksos

    Hyksos Guru

    Joined:
    May 28, 2011
    Messages:
    474
    Likes Received:
    69
    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.
     
  11. awair

    awair Member

    Joined:
    Mar 10, 2009
    Messages:
    86
    Likes Received:
    4
    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...
     
  12. Hyksos

    Hyksos Guru

    Joined:
    May 28, 2011
    Messages:
    474
    Likes Received:
    69
    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 likes this.
  13. wardmundy

    wardmundy Nerd Uno

    Joined:
    Oct 12, 2007
    Messages:
    14,413
    Likes Received:
    2,448
    :iagree: 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.

    [​IMG]

    5.4 should have been 5.4.0.1. My apologies. 5.7 is what you want/need.
     
    Trimline2 likes this.
  14. awair

    awair Member

    Joined:
    Mar 10, 2009
    Messages:
    86
    Likes Received:
    4
    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.
     
  15. Hyksos

    Hyksos Guru

    Joined:
    May 28, 2011
    Messages:
    474
    Likes Received:
    69
    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 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.
     
    wardmundy likes this.
  16. jvangent100

    jvangent100 Member

    Joined:
    Jan 21, 2008
    Messages:
    47
    Likes Received:
    1
    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.
     
  17. Dan Lawrence

    Dan Lawrence Member

    Joined:
    Jan 4, 2008
    Messages:
    44
    Likes Received:
    7
    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.
     
  18. wardmundy

    wardmundy Nerd Uno

    Joined:
    Oct 12, 2007
    Messages:
    14,413
    Likes Received:
    2,448
    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 likes this.
  19. visionlogic

    visionlogic Guru? Nope

    Joined:
    Oct 11, 2009
    Messages:
    117
    Likes Received:
    33

    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.
     
  20. wardmundy

    wardmundy Nerd Uno

    Joined:
    Oct 12, 2007
    Messages:
    14,413
    Likes Received:
    2,448
    That message may only appear on the BeagleBone Black. I couldn't remember which. Thanks.
     
    visionlogic likes this.