CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo
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
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
snort sig: http://seclists.org/snort/2016/q1/285
Anonymous
Feb 17th 2016
8 years ago
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
Anonymous
Feb 17th 2016
8 years ago
- 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
Anonymous
Feb 17th 2016
8 years ago
Anonymous
Feb 17th 2016
8 years ago
Can you please clarify if this will block the issue? Would the specific resolver not still forward the payload to original requestor?
Thanks
Anonymous
Feb 18th 2016
8 years ago
Anonymous
Feb 19th 2016
8 years ago
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.
Anonymous
Feb 19th 2016
8 years ago
Anonymous
Feb 19th 2016
8 years ago
Please refer to the below Debian advisory:
https://security-tracker.debian.org/tracker/CVE-2015-7547
Anonymous
Feb 22nd 2016
8 years ago