Saltar a la navegación Saltar al contenido principal Ir al pie de página

Vulnerability Overview: Ghost (CVE-2015-0235)

27 enero 2015

By Aaron Haymore

This research was originally performed by researchers from iSec Partners (now NCC Group), and has been migrated to research.nccgroup.com for posterity.

Vulnerability Overview: Ghost (CVE-2015-0235)

27 Jan 2015 – Valentin Leon, Jeremiah Blatz

Executive Summary

An alert about a severe vulnerability discovered by the Qualys security team was issued on Tuesday, January 27 2015. This vulnerability allows a local or remote attacker to execute code within the context of an application linked with certain versions of the glibc library. The vulnerability is triggered by a buffer overflow in the gethostbyname() function, called when resolving a hostname to an IP.

Immediate patches are required to fix a vulnerability in glibc that allows arbitrary code execution from unauthenticated users. It is necessary to restart computers or processes following patching.

Ghost enables code execution, arbitrary data disclosure, and system compromise from unauthenticated remote attackers. The ways that a system could be vulnerable to this bug are numerous, and no exhaustive list could be compiled. Patching is required immediately, as a proof-of-concept is soon to be publicly released.

What is vulnerable?

This vulnerability has been in production glibc versions since November 2000, and was patched in source code since May 2013:

  • glibc 2.2 through 2.17 (inclusive) are vulnerable
  • glibc 2.18 through 2.20 (inclusive) are NOT vulnerable
  • prior versions of glibc (<= 2.1.3) are NOT vulnerable

Even if you are not directly using the gethostbyname() function, a large number of software packages incorporate the call and are vulnerable.

Service and software that can be exploited include, but is not limited to:

  • clockdiff
  • procmail
  • pppd (SUID root)
  • Exim Internet Mailer

An exploit has been written against Exim, and a working PoC is soon to be publicly disclosed.

Who is vulnerable?

  • Organizations that ship applications statically linked against vulnerable versions of glibc, or ship appliances built on Linux distributions that have a vulnerable version of glibc. This includes virtual appliances/virtual machines.
  • Organizations or end users that have a Linux desktop or server running with a vulnerable version of glibc, or use applications statically linked against a vulnerable version of glibc. This also extends to appliances and virtual machines. Since this vulnerability has been present in glibc for over a decade, out of date or EOL’d devices are likely to be vulnerable as well.

The following Linux distributions contains a vulnerable version of the glibc: *** *** ## Patching iSEC and Matasano recommend performing the following discovery and remediation steps. ### Discovery First, determine if your Linux is vulnerable. Either consult the [table above](#versions), contact your vendor, or get the version from the version from the library itself. To do the latter, run `locate libc.so.6` to find the location of your libc, then run that file, and it will print out version information. ### Fix If your distribution has patches available, install those patches. Otherwise: * Update to glibc 2.18 or newer * Restart all processes that load the glibc library * Issue new binaries for software statically linked against a vulnerable version of the glibc library. ## Technical Overview The [__nss_hostname_digits_dots()](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nss/digits_dots.c;h=e007ef47a41b69437655c26565689be393705a82;hp=2b862956e9a8c39bbccbea982add1d7ab2d16ab2;hb=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hpb=fef94eab0bd308d5059a2588c753bf9a4926845d) function of the GNU C Library (glibc) is vulnerable to a buffer overflow. This function incorrectly calculates the size of a buffer to allocate, and under certain circumstances, arbitrary data can overwrite adjacent memory resulting in a heap based buffer overflow. While only a maximum of four (4) bytes of memory can be overwritten, it has been demonstrated that this was enough to bypass exploitation mitigations (such as ASLR and PIE) and grant code execution. The `__nss_hostname_digits_dots()` function is usually not called directly but is called from the `gethostbyname()` and `gethostbyname2()` glibc functions. In practice, this can be exploited whenever the hostname passed is long enough (at least 1KB) and passes other sanity checks: * The hostname is composed entirely of digits and dots * The hostname starts and ends with a digit * The hostname must be of the form of `a`, `a.b`, `a.b.c` or `a.b.c.d` ## References * [CVE-2015-0235](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235) * [https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability](https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability) * [https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt](https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt) * [http://ma.ttias.be/critical-glibc-update-cve-2015-0235-gethostbyname-calls/](http://ma.ttias.be/critical-glibc-update-cve-2015-0235-gethostbyname-calls/) * [http://www.frsag.org/pipermail/frsag/2015-January/005722.html](http://www.frsag.org/pipermail/frsag/2015-January/005722.html) * [https://sourceware.org/bugzilla/show_bug.cgi?id=15014](https://sourceware.org/bugzilla/show_bug.cgi?id=15014) * [https://rhn.redhat.com/errata/RHSA-2015-0090.html](https://rhn.redhat.com/errata/RHSA-2015-0090.html) * [https://launchpad.net/ubuntu/+source/eglibc](https://launchpad.net/ubuntu/+source/eglibc) * [https://security-tracker.debian.org/tracker/CVE-2015-0235](https://security-tracker.debian.org/tracker/CVE-2015-0235)

Ubuntu
10.04 LTSfix availablefixed in libc6 2.11.1-0ubuntu7.20
12.04 LTSfix availablefixed in libc6 2.15-0ubuntu10.10
14 and newernot vulnerable

Debian
6.x – squeezevulnerable
6.x – squeeze (LTS)vulnerable
7.x – wheezyvulnerable
7.x – wheezy (security)fix availablefixed in glib 2.13-38+deb7u7
8.0 – jessenot vulnerable
dev – sidnot vulnerable

Red Hat Enterprise fix information
Desktop (v. 5)fix availablefixed in glibc-2.5-123.el5_11.1
Desktop (v. 6)fix availablefixed in glibc-2.12-1.149.el6_6.5
Desktop (v. 7)fix availablefixed in glibc-2.17-55.el7_0.5
HPC Node (v. 6)fix availablefixed in glibc-2.12-1.149.el6_6.5
HPC Node (v. 7)fix availablefixed in glibc-2.17-55.el7_0.5
Server (v. 5)fix availablefixed in glibc-2.5-123.el5_11.1
Server (v. 6)fix availablefixed in glibc-2.12-1.149.el6_6.5
Server (v. 7)fix availablefixed in glibc-2.17-55.el7_0.5
Server EUS (v. 6.6.z)fix availablefixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 6)fix availablefixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 7)fix availablefixed in glibc-2.17-55.el7_0.5
RHEL 4 ELSfix availablefixed in glibc-2.3.4-2.57.el4.2

Mint
13 “Maya”fix availableTracks Ubuntu 12.04, should get update from Ubuntu servers
17 “Qiana”not vulnerable
17.1 “Rebecca”not vulnerable

Gentoo libc information
stablenot vulnerable uses glibc 2.19-r1

Arch fixed in all releases since August 2013, discussion here and package info here
anything recentnot vulnerable

Fedora discussion
19 and earliervulnerableuses glibc 2.17 and earlier
20not vulnerableuses glibc 2.18
21not vulnerableuses glibc 2.20

Mandriva Linux
allvulnerableappears to use glibc 2.16

openSUSE vulnerability information
Enterprise 11 oldervulnerable
Enterprise 12not vulnerable
openSUSE 13.1 newer not vulnerable

Slackware
currentnot vulnerableuses glibc 2.20
14.1 and earliervulnerableuses glibc 2.17 and earlier

Knoppix information about glibc versions
7.2 and earliervulnerableuses glibc 2.17 and earlier
7.4 and laternot vulnerableuses glibc 2.19 and later

Slax
allvulnerableappears to use glibc 2.15

CentOS
CentOS-5fix availablefixed in glibc-2.5-123.el5_11
CentOS-6fix availablefixed in glibc-2.12-1.149.el6_6.5
CentOS-7fix availablefixed in glibc-2.17-55.el7_0.5