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

last updated in Categories , , , ,

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
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

Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin, DevOps engineer, and a trainer for the Linux operating system/Unix shell scripting. Get the latest tutorials on SysAdmin, Linux/Unix and open source topics via RSS/XML feed or weekly email newsletter.

129 comment

  2. 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

    1. 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.

    1. 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.

    2. 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.

      1. 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.

        1. 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.

    3. 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.

    4. 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.

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

  7. 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!

  8. 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

      2. 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.

        1. 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.

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

      1. 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).

  10. 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.

  12. 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.

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

    rpm -q --changelog glibc | grep CVE-2015-0235

  16. 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)

    1. 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.

  17. 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.

    1. 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.

      1. 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…

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

  21. 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

  22. 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!

  23. 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?

  24. 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”

  25. 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.

    1. 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

  27. 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

    2. 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).

    1. 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.

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

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

    1. 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.

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

  38. 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.

  39. 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

      1. 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

        1. 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.

  40. 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….

  41. 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?

  42. 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

  43. 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

  44. 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?

  46. 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

    https://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

  47. 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

  48. 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

  49. 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 :-)

  50. 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

    1. 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
      …..

  51. 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

  54. 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.

  55. 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

  56. 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?

    1. 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”

  57. 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!

  59. 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

    1. 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.

  60. 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

  61. 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

    1. 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

      1. 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.

  62. 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 ?

    1. 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).

  63. 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??

  64. 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!

      1. 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?

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

          1. 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

            1. 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.

  65. 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!

  66. 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.

    1. 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 …

  67. 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.

    Still, have a question? Get help on our forum!

Tagged as: Tags , , ,