Products & Technology

glibc's CVE-2015-7547 and HashiCorp Tools

Feb 18 2016Sean Chittenden

CVE-2015-7547 was announced on the morning of February 16th. We would like to address HashiCorp users on how this affects any HashiCorp tooling.

The significance of this CVE was quickly understood because most versions of glibc in popular Linux distributions were vulnerable to a Remote Code Execution attack. The problem stems from the way glibc's getaddrinfo(3) call mishandle large DNS responses which results in a stack-based buffer overflow.

This statement details the HashiCorp tools which are affected by this CVE and various mitigation steps administrators can take to protect against this vulnerability. Recent updates to our build toolchain have prevented most of our tools from being affected by this vulnerability.

»Status of Tools

The impact of CVE-2015-7547 on HashiCorp tools is limited to only those tools that were compiled using cgo or somehow link to a vulnerable glibc. At the time of this publication, the list of affected and unaffected binaries provided by HashiCorp include:

Tool	Vulnerable	Unaffected	Notes
Consul	`<= 0.5.2`	`>= 0.6.0`
Nomad	All releases	N/A	Patched glibc is required
Otto	N/A	All releases
Packer	`<= 0.7.1`	`>= 0.7.2`
Serf	N/A	All releases
Terraform	`<= 0.6.6`	`>= 0.6.7`
Vagrant	All releases	N/A	Patched glibc is required to the embedded Ruby
Vault	`<= 0.3.0`	`>= 0.3.1`

This is not a vulnerability in HashiCorp's tools; it is a vulnerability in a library (glibc) that specific versions of HashiCorp's tools use at runtime. The correct fix for the affected versions is detailed below and involves upgrading glibc and restarting processes.

If the base OS is running a vulnerable version of glibc and the specific HashiCorp tool is unaffected according to the table above, then the HashiCorp tool remains unaffected because their DNS resolution is performed without using glibc's getaddrinfo(3). Similarly, Vagrant on Mac OS-X or Windows is not vulnerable because its getaddrinfo(3) implementation is not derived from glibc.

»Impact

An attacker who can cause a DNS response to be sent in excess of 2048 bytes for UDP-based queries or 1024 bytes for TCP-based queries and can craft a malicious payload will be able to compromise a vulnerable process with a stack-based buffer overflow.

This is a high-risk vulnerability because this represents a Remote Code Execution (RCE) vulnerability for any affected host even if the host is not directly exposed to the Internet. Both Debian and Red Hat have marked this as a "critical" security issue (Red Hat's highest classification), Ubuntu has released updates on the same day. Many other Linux distributions followed suit with expedited releases, too.

OSes other than Linux are not vulnerable to this RCE (e.g. Alpine Linux, Windows, Mac OS-X, FreeBSD).

»Workaround

There are several workarounds detailed in Google's disclosure announcement on their Security Blog.

»Solution

Perform one of the following:

Recompile your OS's glibc using the following patch provided by Carlos O'Donell from Red Hat: https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
Upgrade your glibc using your distribution's package management framework to a patched version.

For applications running in a container engine (such as Docker), the container must be rebuilt with an upgraded glibc. Upgrading the host's glibc will not impact the glibc in the containers.

After upgrading glibc, it is necessary to restart any process whose age is older than the glibc binary on disk (in many cases this means a reboot).

»References

»Final Thoughts

At HashiCorp, security is a dominant part of our ethos and we are sometimes impacted by elements out of our control (CVE-2015-7547 is a great example of this). While this CVE preempted the majority of the InfoSec news cycle for the week, internally we have been in process of changing our reporting and disclosure handling for our tools and customers. We will announce this new process shortly.

Serf