On February 16, 2016, Google Security announced a new vulnerability in the getaddrinfo() library function of glibc.
The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack.
Refer to https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html for more details.
CVE ID: CVE-2015-7547
CVSSv3 Base Score: 5.9 (CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L)
Vulnerability Details
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. Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR.
A Proof of Concept has been made available simultaneously with this blog post.
What is glibc?
The GNU C Library or glibc is an implementation of the standard C library and a core part of the Linux operating system. Without this library a Linux system will not function. FreeBSD has a similar but different libc library. While the resolver in FreeBSD’s libc and GNU libc share a common ancestry, the bug was introduced when the latter was rewritten to send A and AAAA queries in parallel rather than sequentially when the application requests both.
Product Status
The following products have been confirmed to be not vulnerable to the glibc issue reported as CVE-2015-7547:
- Junos OS does not use glibc and is not affected by this issue.
Note: Linux VM-based platforms (e.g. vSRX, vMX, etc.) include glibc, but do not make use of DNS client libraries during normal operation.
- Junos Space
- ScreenOS uses a different implementation of libc and is not affected by this issue.
- QFabric Director
- JUNOSe
- CTP and CTPView
- NSM server relies on underlying OS glibc library. Contact OS vendor
- NSM appliances running CentOS 4.xx and CentOS 5.7.
Note: Since CentOS 6.5 is vulnerable to this issue, NSM appliances running CentOS 6.5 are also vulnerable. A patch will be made available for appliances running CentOS 6.5 soon.
- SBR Carrier
Note: SBR Carrier running on RHEL relies on the glibc library shipped with the OS. Customers should contact the OS vendor to upgrade glibc.
SBR Carrier running on Solaris is not vulnerable as it does not use this library.
- WX/WXC
- Netscreen IDP
- WL Series
Other products are still under investigation.
Mitigation
The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. One suggested mitigation is to limit the response sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.
In a default libresolv configuration, the UDP-based vector is mitigated by using a trusted, protocol-compliant DNS resolver on a trusted network. A compliant resolver will not produce the kind of oversized responses which are necessary to exploit this vulnerability because by default, the glibc resolver does not enable EDNS0 and does not request large responses.
Current mitigation techniques recommended by Google and RedHat include:
- Limit response sizes accepted by the DNS resolver via TCP.
- Use a trusted, protocol-compliant DNS resolver via UDP.
On an SRX device, when the DNS ALG is enabled (default is enabled), the following option can be specified to limit the DNS response size:
set security alg dns maximum-message-length 2040
MODIFICATION HISTORY:
2016-02-18: Initial publication
2016-02-22: Confirmed ScreenOS not vulnerable. Clarified SBR Carrier statement.
2016-02-26: Confirmed WL Series not vulnerable
RELATED LINKS:
#SIRT