The recent “Ghost” bug has brought some attention to the GNU C Library or glibc. What is glibc?
First, get your Linux systems patched! Patches are available, get your system updated and protected! If you are curious about the details of Ghost, see the announcement from Qualys or their detailed analysis.
OK, now that your system is up to date and protected against that Ghost exploit, what is glibc?
The C standard library contains all the functions C/C++ programs rely upon — standard input/output, memory allocation, math functions, string manipulation, and more. It’s a wrapper around the system calls of the operating system, providing a standard application programming interface to developers. If one copy of the standard libraries can be used by most of the programs on the system, we can save disk space and make maintenance much easier. Glibc is the GNU Project’s implementation of this C standard library. It’s the version you will get with any Linux system.
Any UNIX-family operating system has a file named something like
libc.so*, a shared library file containing these functions. You will find it in
/lib64/libc.so.6 on Linux, while BSD stores it in
/usr/lib/libc.so.version, Solaris in
/lib/libc.so.1, and so on. The system cannot run without it, as most of the programs including the basic system services rely upon shared libraries.
rpm package management command you learn in the Linux server administration course you can quickly and easily answer questions such as:
Hardly anything is completely good or completely bad. As I mentioned, using one common shared library file gives you the benefits of saving storage space and easing maintenance.
But the bad news is that one programming flaw in that library means a vulnerability in every program using the buggy function. That’s what happened in glibc all the way back in 2000, when a buffer overflow vulnerability crept into the
__nss_hostname_digits_dots() function. That is used by the set of
gethostbyname() functions, which resolve hostnames into IP addresses.
The buffer overflow problem was fixed with the release of glibc-2.18, meaning that a fix has been available since May 21, 2013. However, this wasn’t recognized as a potential security problem.
How could that be? No one noticed the buffer overflow. Someone made some enhancements which replaced the code and removed the buggy pieces without realizing that they had been buggy.
This means that popular distributions with conservative attitudes using slightly older versions of packages stayed with the vulnerable glibc-2.17 or even earlier. These include CentOS and Red Hat Enterprise Linux 7 (and of course 6 and earlier), Ubuntu 12.04, and Debian 7. That makes for a lot of vulnerable systems that should have been patched in the past few weeks!
Back to the good news: with glibc being an almost universally used package, much more attention is paid to it. Qualys was carefully examining glibc because it is so important, they weren’t instead looking at uncommonly used software packages.
Here’s what I see on an unpatched Red Hat Enterprise Linux 7 system. The file
libc.so is a small script used by the
ld linker in the final stages of compiling a program. Dynamically linked programs (again, this is almost all of the programs on the system) know to look for
libc.so.6. That’s a symbolic link pointing to the actual shared library file, which is the vulnerable version 2.17 on this system:
$ ls -l /lib64/libc.so* /lib64/libc-* -rwxr-xr-x. 1 root root 2107768 Mar 19 2014 /lib64/libc-2.17.so -rw-r--r--. 1 root root 253 Mar 19 2014 /lib64/libc.so lrwxrwxrwx. 1 root root 12 Dec 16 08:42 /lib64/libc.so.6 -> libc-2.17.so
On a patched system I see this, notice it’s version 2.18:
$ ls -l /lib64/libc.so* /lib64/libc-* -rwxr-xr-x 1 root root 2069160 Dec 21 17:06 /lib64/libc-2.18.so -rw-r--r-- 1 root root 253 Dec 21 17:02 /lib64/libc.so lrwxrwxrwx 1 root root 12 Jan 27 22:00 /lib64/libc.so.6 -> libc-2.18.so
Patches are easy to check and easy to apply, so keep your servers safe!