I made it :-)
I basically followed Gilles's advice and decided to do it properly: i.e. manage a complete cross-compilation of GLIBC. I started from crosstool-ng, and was initially disappointed - seeing that it didn't support my old kernel. I kept at it, though - manually editing the configuration file saved by crosstool-ng to do changes like these on the default arm-gnueabi build configuration:
$ ct-ng arm-unknown-linux-gnueabi
$ ct-ng menuconfig
...
$ vi .config
$ cat .config
...
CT_KERNEL_VERSION="2.6.17"
CT_KERNEL_V_2_6_17=y
CT_LIBC_VERSION="2.13"
CT_LIBC_GLIBC_V_2_13=y
CT_LIBC_GLIBC_MIN_KERNEL_VERSION="2.6.9"
CT_LIBC_GLIBC_MIN_KERNEL="2.6.9
...
$ ct-ng +libc
After numerous tests and failed attempts, the above changes did it - I got a compiled version of GLIBC that would work with my kernel, and copied the resulting files to my Debian Lenny ARM machine:
$ cd .build/arm-unknown-linux-gnueabi/build/build-libc-final/
$ tar zcpf newlibc.tgz $(find . -type f -iname \*.so)
$ scp newlibc.tgz root@mybook:.
I went all the way and moved past squeeze: I debootstrapped a /wheezy and then - very carefully - overwrote the GLIBC versions of the armel-debootstrapped /wheezy
with my own:
# # In the ARM machine
# cd /wheezy/lib/arm-linux-gnueabi/
# mv /var/tmp/ohMyGod/libc.so libc-2.13.so
# mv /var/tmp/ohMyGod/rt/librt.so librt-2.13.so
...
...etc, making sure I didn't miss any shared libraries.
Finally, I copied over the ldd
and ldconfig
binaries (which were also part of GLIBC), and chrooted inside my /wheezy.
It worked.
I can only assume that the compilation of GLIBC from a chroot-ed 'qemu-arm' emulation inside a x86, somehow messed things up - maybe the configure
process detects some stuff from the running environment - whereas the cross-compilation can't be misled.
So naturally I moved to the next step, and used a busybox-static shell to replace the {/bin,/sbin,...} folders of my old lenny with the wheezy ones - and rebooted into my brand new Wheezy :-)
I hereby claim that my WD MyBook World Edition is the only one on the planet running Debian Wheezy :-) If anyone else is interested, I can upload a tarball of the libc files someplace.
Answer to my question, from Qualys:
During our testing, we developed a proof-of-concept in which we send a
specially created e-mail to a mail server and can get a remote shell
to the Linux machine. This bypasses all existing protections (like
ASLR, PIE and NX) on both 32-bit and 64-bit systems.
My compiled research below for anyone else looking:
Disclaimer
Despite what a lot of other threads/blogs might tell you, I suggest not to immediately update every single OS you have blindly without thoroughly testing these glibc
updates. It has been reported that the glibc updates have caused massive application segfaults forcing people to roll back their glibc updates to their previous version.
One does not simply mass-update a production environment without testing.
Background Information
GHOST is a 'buffer overflow' bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker that is able to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.
Impact
The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution.
Current list of affected Linux distros
RHEL (Red Hat Enterprise Linux) version 5.x, 6.x and 7.x
RHEL 4 ELS fix available ---> glibc-2.3.4-2.57.el4.2
Desktop (v. 5) fix available ---> glibc-2.5-123.el5_11.1
Desktop (v. 6) fix available ---> glibc-2.12-1.149.el6_6.5
Desktop (v. 7) fix available ---> glibc-2.17-55.el7_0.5
HPC Node (v. 6) fix available ---> glibc-2.12-1.149.el6_6.5
HPC Node (v. 7) fix available ---> glibc-2.17-55.el7_0.5
Server (v. 5) fix available ---> glibc-2.5-123.el5_11.1
Server (v. 6) fix available ---> glibc-2.12-1.149.el6_6.5
Server (v. 7) fix available ---> glibc-2.17-55.el7_0.5
Server EUS (v. 6.6.z) fix available ---> glibc-2.12-1.149.el6_6.5
Workstation (v. 6) fix available ---> glibc-2.12-1.149.el6_6.5
Workstation (v. 7) fix available ---> glibc-2.17-55.el7_0.5
CentOS Linux version 5.x, 6.x & 7.x
CentOS-5 fix available ---> glibc-2.5-123.el5_11
CentOS-6 fix available ---> glibc-2.12-1.149.el6_6.5
CentOS-7 fix available ---> glibc-2.17-55.el7_0.5
Ubuntu Linux version 10.04, 12.04 LTS
10.04 LTS fix available ---> libc6-2.11.1-0ubuntu7.20
12.04 LTS fix available ---> libc6-2.15-0ubuntu10.10
Debian Linux version 6.x, 7.x
6.x squeeze vulnerable
6.x squeeze (LTS) fix available ---> eglibc-2.11.3-4+deb6u4
7.x wheezy vulnerable
7.x wheezy (security) fix available ---> glib-2.13-38+deb7u7
Linux Mint version 13.0
Mint 13 fix available ---> libc6-2.15-0ubuntu10.10
Fedora Linux version 19 (or older should upgrade)
Fedora 19 - vulnerable - EOL on Jan 6, 2014 (upgrade to Fedora 20/21 for patch)
SUSE Linux Enterprise
Server 10 SP4 LTSS for x86 fix available ---> glibc-2.4-31.113.3
Server 10 SP4 LTSS for AMD64 and Intel EM64T fix available ---> glibc-2.4-31.113.3
Server 10 SP4 LTSS for IBM zSeries 64bit fix available ---> glibc-2.4-31.113.3
Software Development Kit 11 SP3 fix available ---> glibc-2.11.3-17.74.13
Server 11 SP1 LTSS fix available ---> glibc-2.11.1-0.60.1
Server 11 SP2 LTSS fix available ---> glibc-2.11.3-17.45.55.5
Server 11 SP3 (VMware) fix available ---> glibc-2.11.3-17.74.13
Server 11 SP3 fix available ---> glibc-2.11.3-17.74.13
Desktop 11 SP3 fix available ---> glibc-2.11.3-17.74.13
openSUSE (versions older than 11 should upgrade)
11.4 Evergreen fix available ---> glibc-2.11.3-12.66.1
12.3 fix available ---> glibc-2.17-4.17.1
What packages/applications are still using the deleted glibc?
(credits to Gilles)
For CentOS/RHEL/Fedora/Scientific Linux:
lsof -o / | awk '
BEGIN {
while (("rpm -ql glibc | grep \\\\.so\\$" | getline) > 0)
libs[$0] = 1
}
$4 == "DEL" && $8 in libs {print $1, $2}'
For Ubuntu/Debian Linux:
lsof -o / | awk '
BEGIN {
while (("dpkg -L libc6:amd64 | grep \\\\.so\\$" | getline) > 0)
libs[$0] = 1
}
$4 == "DEL" && $8 in libs {print $1, $2}'
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.
GHOST vulnerability check
The University of Chicago is hosting the below script for easy downloading:
$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
[OR]
$ curl -O https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c
$ gcc GHOST.c -o GHOST
$ ./GHOST
[responds vulnerable OR not vulnerable ]
/* 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 ghosttester.c -o ghosttester
$ ./ghosttester
[responds vulnerable OR not vulnerable ]
Red Hat Access Lab: GHOST tool Do not use this tool, its reporting is wrong, the Vulnerability checker from Qualys is accurate.
Patching
CentOS/RHEL/Fedora/Scientific Linux
sudo yum clean all
sudo yum update
Now restart to take affect:
sudo reboot
Alternatively, if your mirror don’t contain the newest packages, just download them manually. *note: For more advanced users
CentOS 5
http://mirror.centos.org/centos/5.11/updates/x86_64/RPMS/
CentOS 6
mkdir ~/ghostupdate
cd ~/ghostupdate
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-devel-2.12-1.149.el6_6.5.x86_64.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-common-2.12-1.149.el6_6.5.x86_64.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/nscd-2.12-1.149.el6_6.5.x86_64.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-static-2.12-1.149.el6_6.5.x86_64.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-headers-2.12-1.149.el6_6.5.x86_64.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-utils-2.12-1.149.el6_6.5.x86_64.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-2.12-1.149.el6_6.5.x86_64.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-static-2.12-1.149.el6_6.5.i686.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-devel-2.12-1.149.el6_6.5.i686.rpm
wget http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/glibc-2.12-1.149.el6_6.5.i686.rpm
yum localupdate *.rpm [OR] rpm -Uvh *.rpm
Ubuntu/Debian Linux
sudo apt-get clean
sudo apt-get update
sudo apt-get dist-upgrade
Restart:
sudo reboot
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
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
Nearly every program running on your machine uses glibc. You need to restart every service or app that uses glibc to ensure the patch takes effect. Therefore, a reboot is recommended.
How to restart init without restarting or affecting the system?
telinit u
' man telinit ' -- U or u to request that the init(8) daemon re-execute itself. This is not recommended since Upstart is currently unable to pre-serve its state, but is necessary when upgrading system libraries.
To immediately mitigate the threat in a limited manner is by disabling reverse DNS checks in all your public facing services. For example, you can disable reverse DNS checks in SSH by setting UseDNS
to no
in your /etc/ssh/sshd_config
.
Sources (and more information):
- https://access.redhat.com/articles/1332213
- http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/
- http://www.openwall.com/lists/oss-security/2015/01/27/9
- https://security.stackexchange.com/questions/80210/ghost-bug-is-there-a-simple-way-to-test-if-my-system-is-secure
- http://bobcares.com/blog/ghost-hunting-resolving-glibc-remote-code-execution-vulnerability-cve-2015-0235-in-centos-red-hat-ubuntu-debian-and-suse-linux-servers
- https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability
- https://security-tracker.debian.org/tracker/CVE-2015-0235
Best Answer
If you're using any reasonably well-supported distribution, you don't need the original patch itself. Most distributions would have updated libc by now, and pushed it to their repositories, and all you need to do is use the package manager to upgrade libc. (If they haven't done so by now, seriously consider switching distributions.) And this is indeed the case with Amazon Linux. From their security bulletins:
The patch if you want to look at it, is the part that begins with
diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
in the email: