Thanks to https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63 for a script to test for this vulnerability.

Update: Another option for Debian, at least, is to check ldd –version

[code]ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u7) 2.13[/code]

Check the last digit in the minor release number, ‘deb7u7’ is good, ‘deb7u6’ or less are vulnerable.

First download the file:

[code]wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c[/code]

If you have a certificate error you may want to use the wget –no-check-certificate option

[code]wget –no-check-certificate https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c[/code]

Then run this to check

[code]gcc gistfile1.c -o CVE-2015-0235[/code]

You may get a gcc file not found error

[code]# gcc gistfile1.c -o CVE-2015-0235
-bash: gcc: command not found[/code]

— I am assuming at this time that it means th GNU LibC glibc is not installed and therefore the system is not vulnerable. Similarly the Synology NAS devices that I use are all showing a null result for glibc.

…..but if gcc is available, then use this to show the result:

[code]./CVE-2015-0235[/code]

Either your will be “vulnerable” or “not vulnerable”

and you can follow my adventures in patching Debian and CentOS / CPanel servers for glibc in another post.

Thanks to https://news.ycombinator.com/item?id=8953545 for linking me to this originally.

So another security issue on Linux.  I have multiple servers to worry about and they are mostly based on two distributions of Debian and CentOS.

Because it is a newly found vulnerability some mirror sites are not up to date so in trying to patch my servers I found the following to be helpful.

Debian

Check this for https://security-tracker.debian.org/tracker/CVE-2015-0235 the Debian versions that are affected.

My Debian Wheezy servers showed:

[code]$ ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u6) 2.13[/code]

or even older

[code]$ ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u4) 2.13[/code]

so I ran the following on them

[code]# apt-get update && apt-get dist-upgrade[/code]

Watching and hitting the Y for yes when prompted. I could have used apt-get upgrade but I figured since I was doing upgrades I might as well do them completely. I like this post for a great explanation of the differences between the two options http://askubuntu.com/questions/194651/why-use-apt-get-upgrade-instead-of-apt-get-dist-upgrade.

and after the patching I get

[code]# ldd –version
ldd (Debian EGLIBC 2.13-38+deb7u7) 2.13[/code]

which tells me that I have the latest and should not be vulnerable.

CentOS

CentOS on one server was version 5.11 and did not want to update anything when I tried to use

[code]# yum update glibc[/code]

So I checked and ran an update but found the same result, ie the mirror that yum used was not giving out a 27th January 2015 update. So I made a change in the /etc/yum.repos.d/CentOS-Base.repo file to comment out the mirrorlist line and enable (uncomment) the baseurl line which goes direct to the CentOS servers that have patches from today that address the issue.

How to tell which version of CentOS you have?

[code]# cat /etc/*release*[/code]

will respond with something like

[code]CentOS release 6.5 (Final)[/code]

So the process is to update glibc specifically and

[code]# yum update glibc[/code]

Which should prompt for and find updates like this:

[code]

Resolving Dependencies
–> Running transaction check
—> Package glibc.i686 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc.i686 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-common.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-common.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-devel.i686 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-devel.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-devel.i686 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-devel.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-headers.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-headers.x86_64 0:2.12-1.149.el6_6.5 will be an update
—> Package glibc-static.x86_64 0:2.12-1.149.el6_6.4 will be updated
—> Package glibc-static.x86_64 0:2.12-1.149.el6_6.5 will be an update
–> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Updating:
glibc i686 2.12-1.149.el6_6.5 updates 4.3 M
glibc x86_64 2.12-1.149.el6_6.5 updates 3.8 M
glibc-common x86_64 2.12-1.149.el6_6.5 updates 14 M
glibc-devel i686 2.12-1.149.el6_6.5 updates 984 k
glibc-devel x86_64 2.12-1.149.el6_6.5 updates 983 k
glibc-headers x86_64 2.12-1.149.el6_6.5 updates 612 k
glibc-static x86_64 2.12-1.149.el6_6.5 updates 1.4 M

Transaction Summary
================================================================================
Upgrade 7 Package(s)

Total download size: 26 M
Is this ok [y/N]:

[/code]

This is where I hit Y for yes and watched it continue to download and upgrade glibc.

Finally for all of the servers I used a test script for CVE-2015-0235 glibc ghost that was provided from elsewhere.

Next is VMWare, Watchguard, and anything else that might have glibc.