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
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
somehow link to a vulnerable
glibc. At the time of this publication, the
list of affected and unaffected binaries provided by HashiCorp include:
|Consul||<= 0.5.2||>= 0.6.0|
|Nomad||All releases||N/A||Patched glibc is required|
|Packer||<= 0.7.1||>= 0.7.2|
|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
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
getaddrinfo(3). Similarly, Vagrant on Mac OS-X or Windows is
not vulnerable because its
getaddrinfo(3) implementation is not derived
An attacker who can cause a DNS response to be sent in excess of
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).
There are several workarounds detailed in Google's disclosure announcement on their Security Blog.
Perform one of the following:
1) Recompile your OS's
glibc using the following patch provided by Carlos
O'Donell from Red Hat:
2) 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).
At HashiCorp, security is a
dominant part of our ethos and we are sometimes impacted by elements out of
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.