The Google Security Team and Red Hat reported the security impact of a new buffer overflow discovered in glibc (GNU C library) 2.9.
The issue affected all the versions of glibc since 2.9: 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.
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.
Remote code execution is possible, but not straightforward.
It requires bypassing the security mitigations present on the system, such as ASLR.
Google’s researchers also provide a simple proof-of-concept
Affected software and devices
Any software or application that connects to things on a network or the Internet and uses glibc is at RISK.
The vulnerability could extend to a nearly all the major software, including:
- Virtually all distributions of Linux.
- Programming languages such as the Python, PHP, and Ruby.
- Many others that use Linux code to lookup the numerical IP address of an Internet domain.
- Most Bitcoin software is reportedly vulnerable.
Who are Not Affected
Android is not vulnerable to this flaw.
A lot of embedded Linux devices, including home routers and various gadgets, are not affected by the bug because these devices use the uclibc library as it is more lightweight than hefty glibc.
Mitigating factors for UDP include:
- A firewall that drops UDP DNS packets > 512 bytes.
- A local resolver (that drops non-compliant responses).
- Avoid dual A and AAAA queries (avoids buffer management error) e.g. Do not use AF_UNSPEC.
- No use of
options edns0in /etc/resolv.conf since EDNS0 allows responses larger than 512 bytes and can lead to valid DNS responses that overflow.
- No use of
RES_USE_DNSSECsince they can both lead to valid large EDNS0-based DNS responses that can overflow.
Mitigating factors for TCP include:
- Limit all replies to 1024 bytes.
Mitigations that don’t work:
options single-requestdoes not change buffer management and does not prevent the exploit.
options single-request-reopendoes not change buffer management and does not prevent the exploit.
- Disabling IPv6 does not disable AAAA queries. The use of AF_UNSPEC
unconditionally enables the dual query.
The use of
sysctl -w net.ipv6.conf.all.disable_ipv6=1will not protect your system from the exploit.
- Blocking IPv6 at a local or intermediate resolver does not work to prevent the exploit. The exploit payload can be delivered in A or AAAA results, it is the parallel query that triggers the buffer management flaw.