SANS ISC: CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • Computer Forensics
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Google researchers Fermin J. Serna and Kevin Stadmeyer today released a blog post stating that they found a stack-based buffer overflow vulnerability in the getaddrinfo function in glibc. This is significant for a number of reasons:

• Pretty much any Linux system uses glibc, and getaddrinfo is typically used to resolve IP addresses. Which means Linux servers as well as workstations, are vulnerable unless it runs an old version of glibc (pre 2.9).
• Google isn't the first one that spotted the bug, but determined it's significance in collaboration with Redhat.
• Google was able to create a PoC exploit. While exploitation depends on the countermeasures systems use for stack based buffer overflows, it is possible to exploit the bug and achieve command execution.
  
  [earlier I mentioned iOS and Android as likely vulnerable. They could be, but they do not include glibc by default, so it would be up to an app to introduce it. Android uses the Bionic libc library.  OS X and iOS do not use glibc neither do other BSD based systems.  Thanks to Ken White for pointing this out]

The exploit will likely trigger a DNS lookup from a vulnerable system. DNS lookups can be triggered in many ways: An image embedded in a web page, an email sent that is processed by a spam filter (which involves DNS lookups) are just two of many options. 

The exploit response will exceed 2048 bytes in size. Not all responses > 2048 are exploits. The response may arrive via TCP or UDP. 

Many modern systems support a feature called "EDNS0". This feature can be used by a client to signal to a server that it is willing to receive UDP responses that are larger than the traditional 512 bytes in size. Features like DNSSEC require EDNS0 to be enabled. Blocking large DNS responses will likely break EDNS0. DNS resolution may fail or will be significantly delayed.

What can you do?

- Patch!
- make sure all systems on your network use a specific resolver and block outbound DNS unless it originates from this resolver (this is a good idea anyway!). This will limit exposure to the resolver
- the advisory has a number of different options available (note that while the bug appears to be related to IPv6 AAAA queries, disabling IPv6 will not mitigate the issue. The exploit payload may still include malicious content).

All versions of glibc after 2.9 are vulnerable. Version 2.9 was introduced in May 2008.

Affected / Not Affected Major Linux Distributions (work in progress)

 

Distribution	Vulnerable (glibc version)
Red Hat Enterprise Linux 5	no (2.5)
Red Hat Enterprise Linux 6	yes (2.12)
Red Hat Enterprise Linux 7	yes (2.17)
Debian squeeze	yes (2.11)
Debian wheezy	yes (2.13)
Debian jessie	yes (2.19)

[1] https://googleonlinesecurity.blogspot.ca/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
[2] https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

PoC: https://github.com/fjserna/CVE-2015-7547
snort sig: http://seclists.org/snort/2016/q1/285

CentOS 7 also patched:
https://lists.centos.org/pipermail/centos-announce/2016-February/021672.html

Oracle Linux advisory here:
http://linux.oracle.com/errata/ELSA-2016-0175.html

F5 Networks statement:
https://support.f5.com/kb/en-us/solutions/public/k/47/sol47098834.html

Is it really as simple as something like this?

- Register a cheapo domain

- Stand up a malicious DNS server for the domain

- Send an email from that domain to your target's Linux SMTP gateway

- The target’s email server does a PTR lookup on the sender

- Game Over

Should also be noted that a malicious DHCP server could send clients to a malicious name server via DHCP option 5

Re: "- make sure all systems on your network use a specific resolver and block outbound DNS unless it originates from this resolver (this is a good idea anyway!). This will limit exposure to the resolver"

Can you please clarify if this will block the issue? Would the specific resolver not still forward the payload to original requestor?

Thanks

What will be the impact of this vulnerability on ICS(industrial Control Systems) ?

I'm not an ICS expert but...
You have to distinct two major components in ICS environments:
- "Sensors" (ex: PLC's)
- Monitoring / Control tools

The first ones do not perform lot of DNS requests and are usually talking with the seconds in restricted environments.
The second ones could be more affected if they make more intensive use of DNS.
If you apply classic security controls (eg segmentation, no Internet access), you should not be (or less) affected.

Busy week for exploits, I've written up some content on validating and mitigating the effect on edge Cisco devices, please check it out if it's of interest to you: http://info.stack8.com/blog/cve20157547-google-glibc-vulnerability-cisco-products

By the way, not all 2.19 glibc Debian jessie versions are vulnerable to CVE-2015-7547.
Please refer to the below Debian advisory:
https://security-tracker.debian.org/tracker/CVE-2015-7547