New Critical GLibc Vulnerability CVE-2015-0235 (aka GHOST)

Published: 2015-01-27
Last Updated: 2015-01-27 23:56:16 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Qualys discovered a critical buffer overflow in the gethostbyname() and gethostbyname2() functions in glibc. According to the announcement by Qualys, they were able to create an in-house exploit that will execute arbitrary code via the Exim mail server. [1]

glibc before version 2.18 (released August ) is vulnerable. You can quickly check your glibc version by using "ldd --version" (but not all Unix systems that use glibc have ldd installed, and some software is statically compiled with glibc)

These glibc functions are used on most (all?) Unix systems to resolve hostnames . Any software that at some point resolved host names is potentially vulnerable, which includes pretty much all software that uses the network in some from (clients and servers). The problem has been fixed in some versions of glibc, but it was originally not recognized as a security vulnerability, and as a result not backported in older, still widely used and supported versions of glibc.

What should you do: Apply this update as soon as you see patched offered by your Linux/Unix distribution. Some Windows software (and of course OS X) uses glibc as well and may be vulnerable. Use the getaddrinfo() function, not gethostbyname()


Additional resources:

You shouldn't be using gethostbyname() anyway - Robert Graham, Errata Security

Highly critical “Ghost” allowing code execution affects most Linux systems - Dan Goodin, Ars Technica

GHOST glibc Remote Code Execution Vulnerability Affects All Linux Systems - Michael Mimoso, Threatpost

Linux Ghost Remote Code Execution Vulnerability - US-CERT

Johannes B. Ullrich, Ph.D.

3 comment(s)


I wouldn't actually overreact here. While this is a serious vulnerablity, it is not easy to exploit and the attack surface is pretty much limited. EXIM has found to be vulnerable by Qualys, but many other major services are not vulnerable (i. e. Postfix, Apache, nginx, lighttpd, pureftpd, proftpd, etc.). This needs to be patched for sure, but I think there is no need to react overhasty, but in a calm and ordered manner instead.
So my understanding is that so far, the only verified attack vector would be a Linux box running SMTP? Or is that an oversimplification?
Suck it Ubuntu nerds, Gentoo is invulnerable...

Diary Archives