Critical glibc buffer overflow vulnerability in getaddrinfo() on Linux (CVE-2015-7547 & CVE-2015-5229)

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, February 16, 2016

Follow me on Twitter as @mattiasgeniar

In early 2015 we were startled by the "Ghost" vulnerability (CVE-2015-0235). Now, it's time for a similar DNS-based remote code execution vulnerability, split into 2 vulnerabilities: CVE-2015-7547 & CVE-2015-5229.

This vulnerability was discovered by Google’s security team.

What’s the vulnerability?

Red Hat has updated details on the vulnerability.

A stack-based buffer overflow was found in the way the libresolv library

performed dual A/AAAA DNS queries. A remote attacker could create a

specially crafted DNS response which could cause libresolv to crash or,

potentially, execute code with the permissions of the user running the

library. Note: this issue is only exposed when libresolv is called from the

nss_dns NSS service module. (CVE-2015-7547)

It was discovered that the calloc implementation in glibc could return

memory areas which contain non-zero bytes. This could result in unexpected

application behavior such as hangs or crashes. (CVE-2015-5229)


The Ghost vulnerability from early 2015 targeted a different, but also DNS related, vulnerability in glibc.

Proof of concept denial-of-service code is available on Github.

The technical explanation of the exploit

This is best provided by Google’s security team themselves.

glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.

Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.

Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow.

The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.

CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

Who’s vulnerable?

Quite a lof systems are potentially vulnerable to this exploit:

Even though the actual exploit isn’t easy due to technologies like ASLR (Address space layout randomization), it’s not impossible for this exploit to wreck havoc.

Possible attack vectors

DNS requests, which are the root of the problem in this case, are caused by a lot of seemingly innocent actions on a server. Each of these, if the DNS server responds with a maliciously crafted response, could trigger the exploit.

  • SSH logins: reverse DNS lookups are performed on each login
  • Mailservers: incoming connections are checked for reverse DNS, DNS blacklists, SPF records are checked, …
  • Curl requests on a server: if an application allows user-input that triggers HTTP(s) fetches, this could trigger the exploit. This means ‘pingback’ services like WordPress offers could be vulnerable, too.

Anything else that does DNS requests is a potential target.

Patching your servers

For Red Hat Enterprise Linux, the packages are already available and can be updated via yum. For CentOS, we’re still awaiting the packages to be synced to all mirrors.

CentOS packages are also available. Everyone can/should update now!.

If the package is available, run the following:

$ yum clean all
$ yum update glibc

After the update, you’re best rebooting your system, as a lot of running services (like SSH, mailservers, …) load the gblic libraries on their startup (1).

If that’s not an option, restart every public-facing service after you’ve updated glibc.

For Red Hat Enterprise Linux 7 and CentOS 7, it should be sufficient to reload systemd after the glibc update.

$ systemctl daemon-reexec

On RHEL 6 / CentOS 6, systemd isn’t present.

(1) If applications are statically linked against glibc, they get their ‘own’ copy of the libraries and need to be restarted. If they use shared libraries (which would be the default) they use glibc as is and do not need to be restarted.

Further reading

If you’re up for it, here are some follow-up links.

Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.