≡ Menu

How To Patch and Protect Linux Server Against the Glibc GHOST Vulnerability # CVE-2015-0235

A very serious security problem has been found in the GNU C Library (Glibc) called GHOST. How can I fix GHOST vulnerability and protect my Linux server against the attack? How do I verify that my server has been fixed against the Glibc GHOST vulnerability?

A very serious security problem has been found and patched in the GNU C Library called Glibc. It was announced on 27th January 2015.

What is the GHOST security bug?


From the RHEL bugzilla:

A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which is used by the gethostbyname() and gethostbyname2() glibc function call. A remote attacker could use this flaw to execute arbitary code with the permissions of the user running the application.

A mailing list entry with more details, including in-depth analysis and exploit vectors is here.

What C library (Glibc) version does my Linux system use?

The easiest way to check the version number is to run the following command:

ldd --version

Sample outputs from RHEL/CentOS Linux v6.6:

ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Sample outputs from Ubuntu Linux 12.04.5 LTS:

ldd (Ubuntu EGLIBC 2.15-0ubuntu10.9) 2.15
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Sample outputs from Debian Linux v7.8:

ldd (Debian EGLIBC 2.13-38+deb7u6) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

A list of affected Linux distros

  • RHEL (Red Hat Enterprise Linux) version 5.x, 6.x and 7.x
  • CentOS Linux version 5.x, 6.x & 7.x
  • Ubuntu Linux version 10.04, 12.04 LTS
  • Debian Linux version 7.x
  • Linux Mint version 13.0
  • Fedora Linux version 19 or older
  • SUSE Linux Enterprise 11 and older (also OpenSuse Linux 11 or older versions).
  • SUSE Linux Enterprise Software Development Kit 11 SP3
  • SUSE Linux Enterprise Server 11 SP3 for VMware
  • SUSE Linux Enterprise Server 11 SP3
  • SUSE Linux Enterprise Server 11 SP2 LTSS
  • SUSE Linux Enterprise Server 11 SP1 LTSS
  • SUSE Linux Enterprise Server 10 SP4 LTSS
  • SUSE Linux Enterprise Desktop 11 SP3
  • Arch Linux glibc version <= 2.18-1

GHOST vulnerability check

You can test or reproduce the bug using the following C code:

/* ghosttest.c:  GHOST vulnerability tester */
/* Credit: http://www.openwall.com/lists/oss-security/2015/01/27/9 */
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
 
#define CANARY "in_the_coal_mine"
 
struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };
 
int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;
 
  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';
 
  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
 
  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

Compile and run it as follows:

$ gcc ghosttest.c -o ghosttest
$ ./ghosttest

Sample outputs from patched Debian v7.8 server:

not vulnerable

Sample outputs from unpatched Ubuntu 12.04 LTS server:

vulnerable

How do list packages/applications depends upon vulnerable Glibc?

Type the following lsof command:

lsof | grep libc | awk '{print $1}' | sort | uniq

Sample outputs from my Debian Linux v7.x nas:

Fig.01: Linux find all the services/applications that rely on the GNU C libraries (Glibc) command

Fig.01: Linux find all the services/applications that rely on the GNU C libraries (Glibc) command

Fix the GHOST vulnerability on a CentOS/RHEL/Fedora/Scientific Linux

Type the following yum command as the root user:

sudo yum clean all
sudo yum update

Finally, reboot RHEL/SL/Fedora/CentOS Linux server by typing the following command:

### Sysadmin should plan on updating as soon as possible or use maintenance reboot window ##
sudo reboot

Sample outputs:

Fig.02 Fix the GHOST vulnerability on a CentOS/RHEL/Fedora/Scientific Linux

Fig.02 Fix the GHOST vulnerability on a CentOS/RHEL/Fedora/Scientific Linux

Fix the GHOST vulnerability on a Ubuntu Linux

Type the following apt-get command as the root user:

sudo apt-get clean
sudo apt-get update
sudo apt-get upgrade
## only run dist-upgrade on a Ubuntu if you want to upgrade kernel too
##sudo apt-get dist-upgrade

Finally, reboot Ubuntu Linux server by typing the following command:

sudo reboot

Sample outputs:

Fig.03: Fix the GHOST vulnerability on a Ubuntu Linux LTS

Fig.03: Fix the GHOST vulnerability on a Ubuntu Linux LTS

Fix the GHOST vulnerability on a Debian Linux

Type the following apt-get command as the root user:

sudo apt-get clean
sudo apt-get update
sudo apt-get upgrade
##No need to do dist-upgrade (see man page: man apt-get)
##sudo apt-get dist-upgrade

Finally, reboot Debian Linux server by typing the following command:

sudo reboot

Sample session:

Gif 01: Fix the GHOST vulnerability on a Debian Linux server

Gif 01: Fix the GHOST vulnerability on a Debian Linux server

Fix the GHOST vulnerability on a SUSE Linux Enterprise

To install this SUSE Security Update use YaST online_update. Or use the following commands as per your version:

SUSE Linux Enterprise Software Development Kit 11 SP3

zypper in -t patch sdksp3-glibc-10206

SUSE Linux Enterprise Server 11 SP3 for VMware

zypper in -t patch slessp3-glibc-10206

SUSE Linux Enterprise Server 11 SP3

zypper in -t patch slessp3-glibc-10206

SUSE Linux Enterprise Server 11 SP2 LTSS

zypper in -t patch slessp2-glibc-10204

SUSE Linux Enterprise Server 11 SP1 LTSS

zypper in -t patch slessp1-glibc-10202

SUSE Linux Enterprise Desktop 11 SP3

zypper in -t patch sledsp3-glibc-10206

Finally run for all SUSE linux version to bring your system up-to-date:

zypper patch

Fix the GHOST vulnerability on a OpenSUSE Linux

To see a list of available updates including glibc on a OpenSUSE Linux, enter:
# zypper lu
To simply update installed glibc packages with their newer available versions, run:

# zypper up

How can I verify that my Linux system no longer vulnerable after the reboot?

Method #1: The easiest way to check vulnerability and/or confirm remediation is to run the following command to verify that you are running an updated version of Glibc:
$ ldd --version

Method #2: Run the instructions given in the previous section called GHOST vulnerability check (generic method for all Linux based systems).

Method #3: If you are RHN subscriber see the Red Hat Access Lab: GHOST tool (only for RHEL/CentOS/SL systems – download link):

#!/bin/bash
# rhel-GHOST-test.sh -  GHOST vulnerability tester. Only for CentOS/RHEL based servers.  #
# Version 3
# Credit : Red Hat, Inc - https://access.redhat.com/labs/ghost/ #
echo "Installed glibc version(s)"
 
rv=0
for glibc_nvr in $( rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc ); do
    glibc_ver=$( echo "$glibc_nvr" | awk -F- '{ print $2 }' )
    glibc_maj=$( echo "$glibc_ver" | awk -F. '{ print $1 }')
    glibc_min=$( echo "$glibc_ver" | awk -F. '{ print $2 }')
 
    echo -n "- $glibc_nvr: "
    if [ "$glibc_maj" -gt 2   -o  \
        \( "$glibc_maj" -eq 2  -a  "$glibc_min" -ge 18 \) ]; then
        # fixed upstream version
        echo 'not vulnerable'
    else
        # all RHEL updates include CVE in rpm %changelog
        if rpm -q --changelog "$glibc_nvr" | grep -q 'CVE-2015-0235'; then
            echo "not vulnerable"
        else
            echo "vulnerable"
            rv=1
        fi
    fi
done
 
if [ $rv -ne 0 ]; then
    cat <<EOF
 
This system is vulnerable to CVE-2015-0235. <https://access.redhat.com/security/cve/CVE-2015-0235>
Please refer to <https://access.redhat.com/articles/1332213> for remediation steps
EOF
fi
 
exit $rv

Sample outputs from patched RHEL v6.8 server:

bash rhel-GHOST-test.sh
Installed glibc version(s)
- glibc-2.12-1.149.el6_6.5.x86_64: not vulnerable
- glibc-2.12-1.149.el6_6.5.i686: not vulnerable
Share this tutorial on:
This entry is 2 of 2 in the Linux GHOST Glibc Critical Security Vulnerability series. Keep reading the rest of the series:
  1. Check Ghost Vulnerability Test Programs
  2. Secure and Patch Your Linux Server For Ghost Bug
{ 129 comments… add one }
  • local January 28, 2015, 8:20 am

    It is time to go on BSD way..

  • Miroslav January 28, 2015, 9:56 am

    Note that, at least on CentOS 6 and likely on RHEL6, the ldd –version command will still return 2.12 even after the update. One can check the rpm package version to see if the system was updated (see the full package list at https://rhn.redhat.com/errata/RHSA-2015-0092.html). The 2.12 library was patched, not replaced by a newer version. For example:

    $ rpm -q glibc
    glibc-2.12-1.149.el6_6.5.i686 <--- patched version
    $ ldd --version
    ldd (GNU libc) 2.12 <--- still 2.12
    
    • nixCraft January 28, 2015, 11:06 am

      Thanks. I’ve posted a script from RHN and C code to for vulnerability check. The ldd --version may not work on all the systems.

  • Brody January 28, 2015, 11:37 am

    Thank you so much for this!

  • Patrick January 28, 2015, 11:52 am

    RHEL 5 is also affected.

    • nixCraft January 28, 2015, 12:01 pm

      Thanks for the heads up. The faq has been updated to include both RHEL 5.x and CentOS 5.x.

  • kevin January 28, 2015, 2:08 pm

    why is it necessary to reboot?

    • bler January 28, 2015, 6:34 pm

      The vulnerability is in glibc. It is used in nearly every program that’s running on your machine. The issue is that you have to restart all those programs after patching to make sure everything is fine. It is hard to list every program that uses glibc so you can just restart your machine instead.

    • Bill January 28, 2015, 8:24 pm

      Reboot is necessary because currently running processes loaded on the old libs, and are vulnerable even after the glibc update. The reboot will force them to read the new libs.

      • Bill January 28, 2015, 8:25 pm

        I stand corrected. I just checked my box after patching it, and it is no longer vulnerable, even without a reboot yet. Probably best to do it anyway.

        • MoChaMan February 3, 2015, 6:20 pm

          You must reboot because *other* programs need to reload GLIBC, some so fundamental you cannot just restart them. When you checked your box, you only ran a program that loaded the newly installed GLIBC. Your box is still vulnerable as long as the other programs are running with the older GLIBC.

    • Torbjørn January 28, 2015, 11:36 pm

      It’s not really necessary to reboot, as long as you make sure to restart all affected services so that they no longer use the old version of libc.

      I just did it on my server, all you need to do (you also need to be root) after upgrading is:
      lsof | grep libc | grep DEL
      Then, go through the list and restart all the services/programs you see.
      Some of them you may need to kill manually (the ones that don’t have scripts in /etc/init.d/) – e.g. getty [run ‘init q’ to restart it and get your consoles back], and processes like bash and sshd won’t end until you log out…

      That said – unless your server is doing something important that shouldn’t be interrupted, a reboot is probably a much quicker and easier solution.

    • Brian January 29, 2015, 12:00 am

      Because running daemons will have already loaded the vulnerable code into memory. Alternatively you could bounce every process on your system one by one, theoretically.

      • Jens January 29, 2015, 11:47 am

        How do you bounce init? :)

        • Spike February 2, 2015, 5:26 pm

          telinit u

    • Tyler January 29, 2015, 1:27 am

      From what I’ve read, there are a lot of services that use glibc, so you can either restart all of them or reboot.

    • Mike January 29, 2015, 4:39 am

      Yes, I agree, is a reboot really nessary?

      • Mike January 29, 2015, 6:51 am

        Thank you everyone for your feedback.

  • Marcelo January 28, 2015, 2:26 pm

    Sweet. Best article I found on how to test it and solve it .

    Tks!

  • Bryan January 28, 2015, 2:58 pm

    For CentOS/RHEL/Fedora/Scientific Linux it might be better to use:

    yum -y update glibc

    This way you are not updating anything else other than glibc. Just a thought. Thanks for posting this by the way!

  • Lavi January 28, 2015, 3:12 pm

    In case I don’t want to run “yum update”, cause that will update all OS RPM packages.
    Can you tell on exact list of RPM packages to be updated?
    The “lsof” command showing who is using glibc, but not all in this list is an RPM.
    Thanks,
    Lavi

    • Miroslav January 28, 2015, 3:16 pm

      You could refer to the list of updated packages (https://rhn.redhat.com/errata/RHSA-2015-0092.html). To make it a bit easier, yum update glibc-* nscd worked as a nice shortcut for me, but you might want to double-check the list of packages yum tells you will be upgraded before allowing it to do so.

      • Lavi January 28, 2015, 3:17 pm

        Thanks!

      • Julius January 28, 2015, 3:50 pm

        nscd is a dependency of glibc, so will be updated automatically.
        I used
        # yum update glibc* -y && reboot
        which gave me unvuln centos 5,6,7 servers..

        centos 4.9 was a problem though.

        • cMax January 29, 2015, 8:34 pm

          Well, if you’re still running CentOS4, you’re intentionally signing up for problems, aren’t you?
          Its End Of Life was 2 years ago.
          It really doesn’t matter what that box is doing; maintaining it is going to be more work and higher risk than migrating its functionality to a modern OS.

  • Eric January 28, 2015, 3:21 pm

    Debian 6 is affected as well even if its EOL people still use it. No glibc installed but the libc6 library files are there.

    • IP3G January 29, 2015, 8:31 am

      Compile from source and install it. Or rebuild deb packages.

      • Ignacio January 29, 2015, 12:06 pm

        Well, it is not entirely true that it is EOL. They made some kind of a LTS version from last Debian, now with security updates up to date (release 6.0.10).

  • Dan at BlackMesh January 28, 2015, 3:25 pm

    If you’re going to “lsof” the entire system, you should add the “-n” flag so you don’t resolve DNS names in open Internet sockets. That will make the operation much faster. Depending on your environment, you may also see a benefit from adding “-l” and “-P” to avoid resolution of usernames and port names, respectively. Finally, on Linux, you can use “-X” to avoid the overhead of searching Internet sockets at all, which can be a huge benefit on a server with tens of thousands of open connections.

  • Remco January 28, 2015, 3:35 pm

    Thanks for sharing. Greatly appreciated.

  • sedwards January 28, 2015, 4:03 pm

    The ‘lsof’ command sample needs ‘sudo’ or a ‘needs to be run by root’ disclaimer.

    The ‘sample output’ shows a shell prompt containing ‘root’ and a ‘#’, but that’s not conclusive or sufficiently obvious.

  • Phil January 28, 2015, 4:18 pm

    The script in method #3 does not work correctly and will retun a fail even if patched, confirmend by RHEL staff (https://access.redhat.com/articles/1332213).

    They are working on an uptated version

  • Bryan January 28, 2015, 4:25 pm

    You can also check if your RHEL/CentOS/CloudLinux is patched by checking its changelog:

    rpm -q --changelog glibc | grep CVE-2015-0235
    
    • Mike January 29, 2015, 12:49 pm

      Thank you, This is very helpful.

  • anon January 28, 2015, 4:54 pm

    anyone have a source for centos/redhat el3 updates?

    • Patrick January 28, 2015, 6:04 pm

      lol, good one.

  • Eoin January 28, 2015, 4:55 pm

    Just ran the suggested ghost vulnerability check on an Ubuntu 8.10 machine and it reported as ‘vulnerable’

    Can you update the page to reflect this ? (i.e. the page states only Ubuntu 12.04 and 10.04 are impacted)

    • Captain Obvious January 28, 2015, 9:32 pm

      Dude, if 12.02 and 10.04 is affected, and anything earlier than glibc 2.17.xxx is affected, OBVIOUSLY Ubuntu 8.10 is affected. Geeesh! Time travel anyone? Maybe you should send this to thedailywtf.com.

  • Graeme January 28, 2015, 4:58 pm

    After clean all and update, I have
    glibc-2.17-21.fc19.x86_64
    which is still vulnerable, is there a repo I’m missing?
    -rw-r–r–. 1 root root 1180 Feb 19 2014 fedora.repo
    -rw-r–r–. 1 root root 1141 Feb 19 2014 fedora-updates.repo
    -rw-r–r–. 1 root root 1199 Feb 19 2014 fedora-updates-testing.repo
    + livna and 8 rpmfusion repos.

    • Bill Mihalo January 29, 2015, 8:16 pm

      It looks as though you are running Fedora 19 which is at End Of Life. Updates are no longer available for this distribution. The easiest solution is to upgrade to Fedora 20 or Fedora 21 using fedup.

      If you don’t have the time to upgrade, you can download a source rpm from vault.centos.org/7.0.1406/updates/Source/SPackages. You need
      glibc-2.17-55.el7_0.5.src.rpm. Download this rpm and issue an rpm -ivh to install it (do this as root). Go into /root/rpmbuild/SPECS and issue an rpmbuild -ba glibc.spec. The build takes about an hour. Afterwards, go into the RPMS folder and select the architecture for your machine. Issue a yum install on all the rpms (you can skip the debug ones if you like) and then reboot.

      • Graeme January 30, 2015, 5:49 am

        Thanks, yes I knew Fedora had a quick development cycle, it’s just that I was quite happy with Fedora 19 :) OK a fedup I will go…

      • ref January 30, 2015, 1:50 pm

        Will this same process work for FC11 and 17?

  • Taras January 28, 2015, 5:11 pm

    Can I patch my system (CentOS 6) without rebooting?

    • nixCraft January 28, 2015, 5:42 pm

      You need to restart every service or app that uses Glibc. Hence, reboot is recommended.

  • Tomas January 28, 2015, 5:22 pm

    Tested your script on Debian 7, Ubuntu 12.04 and Ubuntu 14.04 – not vulnerable.

    • nixCraft January 28, 2015, 5:43 pm

      A bash script or C program? Script only works with RHEL/CentOS/SL systems.

  • Tony January 28, 2015, 6:28 pm

    For SUSE Linux server, run and patch. SUSE Linux Enterprise Software Development Kit 11 SP3:

    zypper in -t patch sdksp3-glibc-10206

    SUSE Linux Enterprise Server 11 SP3:

    zypper in -t patch slessp3-glibc-10206

    SUSE Linux Enterprise Server 11 SP2 LTSS:

    zypper in -t patch slessp2-glibc-10204

    SUSE Linux Enterprise Server 11 SP1 LTSS:

    zypper in -t patch slessp1-glibc-10202

    To apply up-to-date patches, run:

    zypper patch
    • eric wedaa January 28, 2015, 9:16 pm

      what about OpenSUSE 11.0 ? I’m not finding a lot of help online
      :-(

      • Andreas Lang February 2, 2015, 1:07 pm

        I’m looking for that fix for opensuse 11.0
        still no solution found!

  • Tony January 28, 2015, 6:33 pm

    CetOS and RHEL users need to run:

    rpm -q glibc

    A list of safe versions i.e. if the version of glibc is older than the ones listed below, your server is vulnerable and should be patched ASAP:

    RHEL/CentOS 5: glibc-2.5-123.el5_11.1

    RHEL/CentOS 6: glibc-2.12-1.149.el6_6.5

    RHEL/CentOS 7: glibc-2.17-55.el7_0.5

  • MarkL January 28, 2015, 6:40 pm

    Something very important regarding the Ubuntu update commands:

    If your Ubuntu server is running a software package that is distribution dependent, like Zimbra, running the command “sudo apt-get dist-upgrade” will break the application!

    The command to update the packages is “sudo apt-get upgrade” ! Running the “dist-upgrade” will upgrade the Ubuntu release, for instance, upgrading the server from Ubuntu 12 to Ubuntu 14!

  • Matt January 28, 2015, 7:02 pm

    Using a RHEL5 or RHEL 6:
    The bash script shows that severs are “Not Vulnerable.” while the c script shows vulnerable.

    # ./ghost.sh
    Vulnerable glibc version <= 2.17-54
    Vulnerable glibc version <= 2.5-122
    Vulnerable glibc version <= 2.12-1.148
    Detected glibc version 2.5 revision 123
    Not Vulnerable.

    # ./ghosttest
    vulnerable

    ]# ./ghost.sh
    Vulnerable glibc version <= 2.17-54
    Vulnerable glibc version <= 2.5-122
    Vulnerable glibc version <= 2.12-1.148
    Detected glibc version 2.12 revision 149
    Not Vulnerable.

    ]# ./ghosttest
    vulnerable

    So maybe your bash script needs some work?

    • nixCraft January 29, 2015, 5:29 am

      The script has been updated. Please try again on a CentOS/RHEL server.

  • larcher January 28, 2015, 7:21 pm

    That lsof command will catch anything starting with libc (libcrypto, libcolord, libcurl, etc) — not just libc.

    Instead, grep’ing for “libc-” worked for me — since libc shows up as something like “/lib/x86_64-linux-gnu/libc-2.13.so”

  • Jadrian January 28, 2015, 9:03 pm

    What about older versions of Ubuntu? I’m on Ubuntu 13.04 (raring), and I need to stay on this version. If I do

    sudo apt-get clean
    sudo apt-get update
    sudo apt-get dist-upgrade

    Then the response is:

    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    Calculating upgrade… Done
    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

    Are the Ubuntu (and Kubuntu, which I’m actually running) folks not pushing this patch to their old-releases repos? For example, when I do the apt-get update, these lines show up:

    Hit http://old-releases.ubuntu.com raring-security Release.gpg
    […]
    Hit http://old-releases.ubuntu.com raring-security Release

    I know 13.04 isn’t a long-term support release, but you’d figure that truly critical security patches like this would be backported.

    • Dan January 29, 2015, 12:20 pm

      Same problem here!
      How can I upgrade glibc using Ubuntu 13.04 and ubuntu 12.10 ?
      Using the steps for ubuntu I get the same result as Jadrian.

      Reading package lists… Done
      Building dependency tree
      Reading state information… Done
      Calculating upgrade… Done
      0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

      Would appreciate If someone can give us an idea.
      Compiling glibc by hand is not that easy and a little bit risky.
      Thanks

  • Michal January 28, 2015, 9:21 pm

    Thanks! It’s very helpful.

  • spirit January 28, 2015, 10:02 pm

    I’d have a care with
    `sudo apt-get dist-upgrade`…
    sledgehammer and nut spring to mind.

    `sudo apt-get upgrade` should be sufficient.

    – 0

  • Joe January 29, 2015, 2:28 am

    Q. Why must i reboot my system? Why cant i simply restart the services utilizing glibc?

    • nixCraft January 29, 2015, 5:46 am

      See earlier comments by others.

    • Cody February 9, 2016, 1:58 am

      For instance, when nixCraft says see other comments you might include those that point out it isn’t necessary – as long as you know how to restart the affected services (and know which services are affected).

  • venkat January 29, 2015, 3:54 am

    Is Suse 11 SP3 affected?

  • IP3G January 29, 2015, 6:07 am

    Hey,

    Noob question. Is my FreeBSD server affected?

    • nixCraft January 29, 2015, 6:12 am

      Noop. FreeBSD is not affected. But, if you are using a “Linux Binary Compatibility” on a FreeBSD laptop/desktop/server, upgrade “linux-base” port. See this page for more info.

      TL:DR: Upgrade “linux_base-c6” and “linux_base-f10” ports if you are using those.

      • kind January 29, 2015, 8:12 am

        rhn 5.3 client is not this weak version?

  • dxman January 29, 2015, 6:44 am

    @nixCraft.
    what if no updates are released by Distro Developers , i have a server running 11.0 suse. what should i do ?

  • Ken January 29, 2015, 8:04 am

    Should I be re-compiling some binares? Like I installed bind from its source tarball, would I need to recompile bind now?

  • oll January 29, 2015, 8:19 am

    Are you sure you need to reboot ? At least for CentOS6 ?
    Is not restating services enough ?
    I tested with openwall program : http://www.openwall.com/lists/oss-security/2015/01/27/9
    and had “vulnerable”. Then after a yum update glibc, I had “non vulnerable” .
    (I have 50+ servers :-( all quite busy )

    • Miroslav January 29, 2015, 9:17 am

      It said “not vulnerable” because you started the test application after installing the patched library, hence the test application loaded and used the patched version. All the programs that were already running, however, are still using the unpatched library version because they loaded it before you did the update. See earlier comments on this – while it is theoretically possible to do so without rebooting the system, libc is used by so many applications that it might be easier just to reboot. YMMV, of course. See the article and comments on ways to determine what processes (applications) are currently using libc and therefore should be restarted.

  • Prasad January 29, 2015, 11:19 am

    Does anybody know if Red Hat Enterprise Linux Server release 5.7 (Tikanga) is vulnerable to GHOST (CVE-2015-0235)?

    • Prasad January 29, 2015, 11:48 am

      in addition to this – is Oracle database affected?

  • Zoran January 29, 2015, 11:37 am

    On Fedora 18 I also have the vulnerability with latest glibc. Probably we need to go for Fedora 20/21 . .

  • Loz Bigrave January 29, 2015, 11:50 am

    Excellent article.

  • kim January 29, 2015, 12:16 pm

    What about older versions of Fedora?

    I’m on Fedora 8, and I need to stay on this version.

  • Dennis January 29, 2015, 12:33 pm

    Doing zypper up on my OpenSUSE system broke my server! MySQL won’t start anymore and iptables is giving me hell when i use the default GRUB option.

  • Steven January 29, 2015, 2:19 pm

    Most Recent distos with support got the patches going
    but what about old servers :)
    Would be nice to have some glibc patches for all the versions from 2.2 to 2.17 so we could rebuild our own packages

    • kim January 29, 2015, 11:35 pm

      I agree.

      • ranjith January 30, 2015, 5:03 am

        my server is asid to vulnerable . when i’m try update it shows conflicts file . Please help me to fix this problem .

        [root@IPFVM2 UyfQ317At]# rpm -qi glibc
        Name        : glibc                        Relocations: (not relocatable)
        Version     : 2.5                               Vendor: CentOS
        Release     : 81.el5_8.7                    Build Date: Mon 27 Aug 2012 07:53:14 PM IST
        Install Date: Mon 31 Dec 2012 01:06:04 PM IST      Build Host: builder10.centos.org
        Group       : System Environment/Libraries   Source RPM: glibc-2.5-81.el5_8.7.src.rpm
        Size        : 12996741                         License: LGPL
        Signature   : DSA/SHA1, Mon 27 Aug 2012 10:15:44 PM IST, Key ID a8a447dce8562897
        Summary     : The GNU libc libraries.
        Description :
        The glibc package contains standard libraries which are used by
        multiple programs on the system. In order to save disk space and
        memory, as well as to make upgrading easier, common system code is
        kept in one place and shared between programs. This particular package
        contains the most important sets of shared libraries: the standard C
        library and the standard math library. Without these two libraries, a
        Linux system will not function.
        Name        : glibc                        Relocations: (not relocatable)
        Version     : 2.5                               Vendor: CentOS
        Release     : 81.el5_8.7                    Build Date: Mon 27 Aug 2012 07:30:23 PM IST
        Install Date: Mon 31 Dec 2012 01:06:05 PM IST      Build Host: builder10.centos.org
        Group       : System Environment/Libraries   Source RPM: glibc-2.5-81.el5_8.7.src.rpm
        Size        : 11674729                         License: LGPL
        Signature   : DSA/SHA1, Mon 27 Aug 2012 10:15:44 PM IST, Key ID a8a447dce8562897
        Summary     : The GNU libc libraries.
        Description :
        The glibc package contains standard libraries which are used by
        multiple programs on the system. In order to save disk space and
        memory, as well as to make upgrading easier, common system code is
        kept in one place and shared between programs. This particular package
        contains the most important sets of shared libraries: the standard C
        library and the standard math library. Without these two libraries, a
        Linux system will not function.
        [root@IPFVM2 UyfQ317At]# uname -a
        Linux IPFVM2 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
        [root@IPFVM2 UyfQ317At]#
        [root@IPFVM2 UyfQ317At]# yum update glibc-devel ncsd
        Loaded plugins: fastestmirror
        Loading mirror speeds from cached hostfile
         * addons: centos.excellmedia.net
         * base: centos.excellmedia.net
         * epel: mirrors.123host.vn
         * extras: centos.excellmedia.net
         * rpmforge: mirror.smartmedia.net.id
         * rpmforge-extras: mirror.smartmedia.net.id
         * rpmforge-testing: mirror.smartmedia.net.id
         * updates: centos.excellmedia.net
        Reducing CentOS-5 - Base to included packages only
        Finished
        Reducing CentOS-5 Testing to included packages only
        Finished
        Reducing CentOS-5 - Extras to included packages only
        Finished
        Reducing CentOS-5 - Updates to included packages only
        Finished
        Setting up Update Process
        No Match for argument: ncsd
        No package ncsd available.
        No Packages marked for Update
        
        • cmax February 9, 2015, 7:19 pm

          Try ‘yum clean all’ then repeat the update.

          There was a naming convention change a while back, and your local cached list may be out of sync.

  • Jeroen January 29, 2015, 8:55 pm

    I can’t find anything about OpenSuse 11.3. Does anyone know how to update this server. I know there are new OpenSuse versions, but I can’t do it with this specific server, so I would like to know how to update glibc by hand….

  • Mark January 29, 2015, 9:15 pm

    I’m running Ubuntu 12.04 LTS (GNU/Linux 3.2.0-53-generic x86_64) and did not have to do a distro upgrade, I used:

    sudo apt-get -y update && sudo apt-get -y install libc6

    without rebooting and the test method above shows “not vulnerable”; it showed “vulnerable” before the update of libc6

    Is there a reason why this would not work?

  • Srini January 30, 2015, 3:51 am

    Hi experts,

    I don’t find the SUSE patches mentioned (i.e. slessp2-glibc-10204) in the suse site in the repository. I have enabled all my SLES 11 SP2 core and updates repository. DO any one know what repository I need to add for the fixed glibc version?

    Thanks

  • jim dalton January 30, 2015, 9:46 am

    A question obvious to some but not to me: I have some old RH installs eg RH ES3 which are marked as not affected in the overall declaration of the problem, but both the script and the code both state vulnerable. The openwall doc says glibc-2.2 was vulnerable, I’ve got 2.3.2 on my ES3 box for, yet ES3 not listed as vulnerable.
    So I’ve missed the bit that says why the issue only affects RHEL5,6,7: anyone care to point me to the relevant documentation?
    Thx,jim

  • amol January 30, 2015, 9:48 am

    I’ve CentOS 6.0 servers which I cant update. The bug fixed packages r for CentOS 6.5 – according to their names. Can I update only glibc without updating kernel or other packages?

  • Yassin January 30, 2015, 9:57 am

    Do we have an updated yum repository to install updated packages from to fix this issue ?

  • Bernardo January 30, 2015, 10:45 am

    For those who have debian 6 (squeeze). That’s what I did:

    1 – Add this line /etc/apt/sources.list
    deb http://ftp.us.debian.org/debian squeeze-lts main non-free contrib

    2 – check and update list packages
    apt-get update

    3 – verify if it shows (2.11.3-4+deb6u4)
    apt-show-versions libc6

    4 – update only the package
    apt-get install –only-upgrade libc6

    5 – verify again
    apt-show-versions libc6

    6 – check again the vulnerabilty using the C code of this site.

    7 – you can comment the line added in /etc/apt/sources.list

    http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/
    https://security-tracker.debian.org/tracker/CVE-2015-0235

  • jim dalton January 30, 2015, 12:00 pm

    Actually I’ve answered my own question. They are vulnerable, its just that RH don’t support them. That’s is a bit misleading of RH.
    Jim

  • Mani January 30, 2015, 1:33 pm

    for ubuntu 12.04 only following command is enough to get eglibc ldd (Ubuntu EGLIBC 2.15-0ubuntu10.10) 2.15

    apt-get install libc-bin libc6 libc6-i386

  • Tony, London January 30, 2015, 5:10 pm

    Hi – just a quick note to say thanks so much for publishing this guide. 1&1 (major UK hosting provider) has emailed a link to your article to all its customers, which is how I found it.

    Thanks again :-)

  • Nicolas January 30, 2015, 6:52 pm

    Bonjour,

    1°-) Je suis novice et je ne sais pas comment faire pour connaître la version de Glibc que j’ai ?
    Merci pour votre aide pour me donner le pas à pas.
    2°-) Si je suis vulnérable, merci pour me donner le pas à pas pour réparer.

    Je vous remercie pour les personnes qui me répondrons.

    Bien cordialement

    Nicolas

    • jaime January 30, 2015, 9:16 pm

      pour redhat
      exécutez

      [ec2-user@my-hostname ~]$ sudo yum info glibc
      Loaded plugins: fastestmirror
      Loading mirror speeds from cached hostfile
      * epel: mirrors.cat.pdx.edu
      Installed Packages
      Name : glibc
      Arch : x86_64
      Version : 2.12
      …..

  • Nicolas January 30, 2015, 6:54 pm

    Hi,

    1 -) I am new and I do not know how to check which version of glibc I have?
    Thank you for your help to give me step by step.
    2 -) If I’m vulnerable, thank you for giving me the step by step to repair.

    Thank you for the people who answer me.

    Nicolas

  • yamo' January 31, 2015, 8:01 am

    Why apt-get clean? It is useless.
    For Debian LTS it is solved see : https://wiki.debian.org/fr/LTS/Using

  • Sanu February 2, 2015, 9:32 am

    Cheers

  • Al February 2, 2015, 11:29 am

    According to Symnatec: glibc versions 2.2 through 2.17 (inclusive) are vulnerable. Versions 2.18 through 2.20 (inclusive) or under 2.1.3 (inclusive) are NOT vulnerable.

  • Constantine Shuluypin February 2, 2015, 2:29 pm

    https://github.com/makelinux/CVE-2015-0235-workaround

    CVE-2015-0235-workaround aka GHOST glibc vulnerability

    A shared library wrapper with additional checks for the vulnerable functions gethostbyname2_r and gethostbyname_r .

    The proper solution for CVE-2015-0235 is to upgrade glibc to at least glibc-2.18.

    In some cases, an immediate glibc upgrade is not possible, for example in custom production embedded systems, because such an upgrade requires a validation of the whole system.

    In such cases, this workaround provides a hot fix solution, which is easier to validate.

    See https://github.com/makelinux/CVE-2015-0235-workaround

  • Martin February 2, 2015, 2:42 pm

    I am alittle bit confused here, CVE-2015-0235 says that all version before 2.18 is vulnerable. I have some old Ubuntu 12.04 servers. I have updated them to 12.04.5 and after that they get version 2.15, and when I run the GCC GHOST vulnerability check from above it says “not vulnerable”. I guess 2.15 is a patched version then and I do not need a version above 2.18, or am I wrong?

    • Martin February 3, 2015, 1:41 pm

      I can answer my own question, the answer is that 2.15 is the patched version, you can see that by running “apt-get changelog libc6”

  • PhilG February 3, 2015, 8:40 pm

    Thanks for the info. I have upgraded all our RHEL4 – 7 servers, but was wondering if there is ANYTHING that can help with securing/patching RH 9 and RHEL3?

    Thank you!

  • Robert Redl February 4, 2015, 2:12 am

    Thank you for the detailed article

  • TK February 9, 2015, 1:18 pm

    Please help me out. have done yum update glibc
    l managed to patch to glibc 2.5.123 and am i still vulnerable because its under 2.17. am using Centos 5.11.
    if so what should i do to curb this. Kindly Assist

    • MoChaMan February 9, 2015, 8:42 pm

      2.5.123 is the latest, patched version of GLIBC for CentOS 5. It was uploaded 27 January 2015 You do not need to do anything more than reboot.

  • Jim February 10, 2015, 12:47 pm

    For the really old legacy servers that cannot be upgraded, for example Fedora release 8 (Werewolf) and Ubuntu 7.10 gutsy
    I did the following:

    wget –no-check-certificate https://github.com/makelinux/CVE-2015-0235-workaround/archive/master.zip -O master.zip
    unzip master.zip
    make

    (as root) make install
    echo gethostbyname_wrap.so >> /etc/ld.so.preload

    for my fedora install i had to copy the file to the right directory:
    cp /usr/lib/gethostbyname_wrap.so /usr/lib64/gethostbyname_wrap.so

    When you are done you should restart all services that depend on glibc (see previous posts how to lsof grep them) or restart the entire server

  • Gordon Delgado February 12, 2015, 7:26 pm

    OK, so you tell me how:

    “The easiest way to check the version number is to run the following command:
    ldd –version”

    …but you don’t tell me what versions are vulnerable.

    -1

    • nixCraft February 12, 2015, 8:17 pm

      Distro: Version
      Ubuntu 12.04 LTS: 2.15-0ubuntu10.10
      Ubuntu 10.04 LTS: 2.11.1-0ubuntu7.20
      Debian 7 LTS: 2.13-38+deb7u7
      CentOS 5: glibc-2.5-123.el5_11.1
      CentOS 6: glibc-2.12-1.149.el6_6.5
      CentOS 7: glibc-2.17-55.el7_0.5
      RHEL 5: glibc-2.5-123.el5_11.1
      RHEL 6: glibc-2.12-1.149.el6_6.5
      RHEL 7: glibc-2.17-55.el7_0.5

      • MoChaMan February 12, 2015, 8:42 pm

        I think NixCraft has posted a list of the patched versions of GLIBC not the vulnerable versions. These RPMs are the latest, all uploaded on 27 January 2015 so I don’t believe they’re vulnerable. Thanks to NixCraft / Vivek Gite for creating an excellent site full of great tutorials.

  • amol February 15, 2015, 3:12 pm

    I’ve CentOS 6.0 server with glibc-2.12-1.7.el6.x86_64. Now if I update it to glibc-2.12-1.149.el6_6.5, do I need to recompile my C/C++ apps ?

    • Cody February 9, 2016, 2:02 am

      For future reference:

      You would only have to recompile them if you statically link to the affected libraries. If you don’t know whether it is statically linked (or what that means) you’re probably OK (though there are ways to check but I won’t get into those).

      Otherwise you’d only have to restart whatever uses the libraries (or if they aren’t loaded then you shouldn’t need to do anything at all other than update the libraries).

  • Tdv March 5, 2015, 10:48 pm

    I ran the gcc command on Ubuntu Server 8, and it says gcc is not installed. It suggests running apt-get install gcc. But that doesn’t work, since no packages can be downloaded to 8. Should I just do what Jim suggests 5 posts up, for really old legacy servers??

    • Jim March 6, 2015, 3:11 pm

      Ubuntu 8.04 LTS can easily be upgraded to 10.04 LTS
      And 10.04 LTS is still supported for a few months, so has all the necessary updates.

      You may need to add some new sources to your apt config:
      https://help.ubuntu.com/community/EOLUpgrades

  • Gaz March 7, 2015, 1:02 pm

    Maybe I’ve overlooked this already in the thread, but is there an offline installer to patch RHEL 5? I’m unable to allow internet access to our servers in question, so YUM etc is out of the question. Any help appreciated, thank!

    • yamo' March 7, 2015, 2:15 pm
      • Gaz March 7, 2015, 2:19 pm

        Thanks for the link, but I don’t think it helps me as I cant access the internet from my RHEL 5 servers. I’m looking for a link to download the rpm’s from, maybe in tar / zip format?

        • yamo' March 7, 2015, 4:54 pm

          Don’t you have another RHEL 5 to download the file? Or ask to Oracle support the rpm file(s).

          • Gaz March 7, 2015, 4:56 pm

            Unfortunately I don’t have any RHEL servers in the DMZ to download from, that’s my main issue. I’ll see if Oracle can provide us the required rpm’s, I was just hoping to get them from my windows laptop, though this isn’t looking likely. Thanks for your help anyway

            • MoChaMan March 7, 2015, 5:40 pm

              My suggestion is to go to a CentOS 5 mirror and download the required RPMs manually to some other machine, then copy the RPMs to a USB key which you can then insert in the server in question. I like to use the Rackspace mirror. Here’s the link to the x86_64 RPMs:

              http://mirror.rackspace.com/centos/5/updates/x86_64/RPMS/

              I don’t have the full list of RPMs you need but you can keep running:

              rpm –test -Uvh *.rpm

              until the upgrade goes cleanly, then remove –test.

  • Raghu Rao May 1, 2015, 4:36 pm

    Hi,
    We have SUSE Linux. As per this I have to run the following
    SUSE Linux Enterprise Server 11 SP2 LTSS: zypper in -t patch slessp2-glibc-10204
    However, due to firewall if I cannot do an update what are all the packages that I need to download for this? and what are the zypper commands to apply those packages? Appreciate any help in this regard.

    Thanks!

  • me1122 June 6, 2015, 9:12 am

    Hi,

    I want to solve Ghost vulnerability on Fedora release 8 (Werewolf), but it is vulnerable after running update commands. please guide me.

    thanks in advance.

    • Cody February 9, 2016, 1:55 am

      Seriously? You’re using Fedora 8 in 2015 ? That’s incredibly irresponsible and even if you aren’t concerned for your own network (and shame on you for your recklessness) it affects devices across the Internet (right good job making the Internet even less safe than it already has to be). To be using Fedora 8 in 2015… I really hope you’re not an administrator and frankly you’re just as bad as those still using Windows 9x (or more recently XP) – and shouldn’t be allowed to use computers (or any Internet capable device – if not more than that). I’d go so far as to say you shouldn’t be allowed to do a lot more than just use a computer but I’ll not get into that.

      I’m not going to even remark on the rest of your message because you have far more serious problems than CVEs for some years …

  • Cody February 9, 2016, 1:49 am

    Yeah, it’s old but I want to point several things out.

    Rebooting is only necessary for this if you don’t know how shared libraries work (and/or for some reason you ‘cannot’ restart a service). In the case a binary links it statically they would have to recompile it anyway (and therefore restart the service .. sort of like when dynamically linked but with the latter it is only necessary to compile the library) and in the case of dynamic you need only restart the service.

    Furthermore the bug was for older socket code i.e. those that use (as the report indicates) gethostby* family in this case. I can’t remember the last time I used a struct hostent and it’s been declared obsolete for years (and POSIX-1.2008 removed the specification). I’m not saying that nothing uses it (I’m aware of some services that do) but it’s not as common as it used to be (this was also true when this CVE was published).

    In addition, the only time you need reboot a server (unsure on Windows and I don’t deal with Macs but more likely to match Linux as it’s based on NeXTSTEP and some BSD (?)) is if you need to load a kernel. I’m obviously ignoring specific cases like changing SELinux (disabling, enabling, …) and I’m also ignoring hardware (e.g. not hot swappable) upgrades (whatever); I’m only talking about software updates. There are perhaps some rare exceptions but this is all part of the beauty of shared libraries (and other things).

    Lastly, on the subject of different distributions keep in mind that:

    a) some will backport fixes (CentOS does this frequently as it maintains stability due to not have so many updates – and it is for a server after all) i.e. it patches in the fixes (of the more recent release) into the old (hence ‘backport’). Yes this means you might have an update despite what the version claims and in addition (and this is really important!!) you shouldn’t assume (ever, really) that you don’t have the updates; if you’re going to use a binary distribution don’t mix how you install things into the system (user specific or when there isn’t a package is one thing but assuming you don’t have the latest simply because the version is an older version is incorrect).

    b) (As a general point to consider) sometimes a distribution will have a different version (openssl comes to mind here with one of the recent CVEs) and therefore won’t need to be updated.

Leave a Comment


   Tagged with: , , ,