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:
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:
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:
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:
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
- Check Ghost Vulnerability Test Programs
- Secure and Patch Your Linux Server For Ghost Bug
129 comment
It is time to go on BSD way..
Nice try ! :p
So why version 9.3 of FreeBSD is vulnerable?
https://forums.freebsd.org/threads/is-freebsd-vulnerable-to-ghost.50166/
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:
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.
Thank you so much for this!
RHEL 5 is also affected.
Thanks for the heads up. The faq has been updated to include both RHEL 5.x and CentOS 5.x.
why is it necessary to reboot?
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.
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.
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.
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.
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.
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.
How do you bounce init? :)
telinit u
From what I’ve read, there are a lot of services that use glibc, so you can either restart all of them or reboot.
Yes, I agree, is a reboot really nessary?
Thank you everyone for your feedback.
Sweet. Best article I found on how to test it and solve it .
Tks!
For CentOS/RHEL/Fedora/Scientific Linux it might be better to use:
This way you are not updating anything else other than glibc. Just a thought. Thanks for posting this by the way!
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
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.
Thanks!
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.
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.
Debian 6 is affected as well even if its EOL people still use it. No glibc installed but the libc6 library files are there.
Compile from source and install it. Or rebuild deb packages.
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).
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.
Thanks for sharing. Greatly appreciated.
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.
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
You can also check if your RHEL/CentOS/CloudLinux is patched by checking its changelog:
Thank you, This is very helpful.
anyone have a source for centos/redhat el3 updates?
lol, good one.
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)
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.
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.
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.
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…
Will this same process work for FC11 and 17?
Can I patch my system (CentOS 6) without rebooting?
You need to restart every service or app that uses Glibc. Hence, reboot is recommended.
Tested your script on Debian 7, Ubuntu 12.04 and Ubuntu 14.04 – not vulnerable.
A bash script or C program? Script only works with RHEL/CentOS/SL systems.
For SUSE Linux server, run and patch. SUSE Linux Enterprise Software Development Kit 11 SP3:
SUSE Linux Enterprise Server 11 SP3:
SUSE Linux Enterprise Server 11 SP2 LTSS:
SUSE Linux Enterprise Server 11 SP1 LTSS:
To apply up-to-date patches, run:
what about OpenSUSE 11.0 ? I’m not finding a lot of help online
:-(
I’m looking for that fix for opensuse 11.0
still no solution found!
CetOS and RHEL users need to run:
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
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!
Thanks! The page has been updated.
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?
The script has been updated. Please try again on a CentOS/RHEL server.
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”
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.
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
Thanks! It’s very helpful.
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
Thanks! The page has been updated.
Q. Why must i reboot my system? Why cant i simply restart the services utilizing glibc?
See earlier comments by others.
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).
Is Suse 11 SP3 affected?
Yes. See tony posted commands.
Hey,
Noob question. Is my FreeBSD server affected?
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.
rhn 5.3 client is not this weak version?
@nixCraft.
what if no updates are released by Distro Developers , i have a server running 11.0 suse. what should i do ?
Suse has released updates, see:
http://support.novell.com/security/cve/CVE-2015-0235.html
Also, see commands posted by Tony in this thread about patching Suse Linux server.
Should I be re-compiling some binares? Like I installed bind from its source tarball, would I need to recompile bind now?
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 )
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.
Does anybody know if Red Hat Enterprise Linux Server release 5.7 (Tikanga) is vulnerable to GHOST (CVE-2015-0235)?
in addition to this – is Oracle database affected?
On Fedora 18 I also have the vulnerability with latest glibc. Probably we need to go for Fedora 20/21 . .
Excellent article.
What about older versions of Fedora?
I’m on Fedora 8, and I need to stay on this version.
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.
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
I agree.
my server is asid to vulnerable . when i’m try update it shows conflicts file . Please help me to fix this problem .
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.
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….
You can also follow this thread where i asked the same question.
http://www.vicidial.org/VICIDIALforum/viewtopic.php?f=4&t=34015
Don’t do zypper up since it will wreck your system.
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?
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
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
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?
Do we have an updated yum repository to install updated packages from to fix this issue ?
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
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
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
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 :-)
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
pour redhat
exécutez
[[email protected] ~]$ 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
…..
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
Why apt-get clean? It is useless.
For Debian LTS it is solved see : https://wiki.debian.org/fr/LTS/Using
Cheers
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.
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
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?
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”
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!
Thank you for the detailed article
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
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.
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
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
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
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.
Thank you for the kind words!
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 ?
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).
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??
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
Thanks so much, Jim!
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!
http://www.cyberciti.biz/faq/yum-downloadonly-plugin/
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?
Don’t you have another RHEL 5 to download the file? Or ask to Oracle support the rpm file(s).
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
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.
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!
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.
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 …
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.