Glibc Vulnerability Report

This report details a critical vulnerability found in the GNU C Library (glibc), specifically focusing on CVE-2015-7547. The vulnerability, a stack-based buffer overflow in the DNS resolver, allows remote attackers to potentially execute arbitrary code or cause denial-of-service. The report thoroughly expl...Read More

Executive Summary
Google engineers published a blog about a vulnerability which was found in all versions of
glibc since 2.9. The post was published on February 16 2016. As per the blog post, the client
side of glibc DNS resolver is prone to stack-based buffer overflow. When multiple buffer
overflows in send_dg and send_vc functions in the libresolve library in GNU C library, end
up allowing remote attackers to gain access and cause denial of service or may even execute
arbitrary code through altered DNS response. This in tuen triggers a call to the getddrinfo()
with address family: AF_UNSPEC or AF_INET6. It is related to executing “dual A/AAAA
DNS queries” along with libnss_dns.so.2 NSS module. Any software may be altered using
this function with domain names controlled by the attacker or through an attack via man-in-
the-middle.

Technical Description
Vulnerability Description
The GNU C Library is ordinarily utilized for standard framework calls by programs written
in C and C++. Six vulnerabilities of the GNU glibc library on Linux disseminations have
been accounted for in February sixteenth 2016 that could enable a remote aggressor to
execute subjective code on a powerless framework. These vulnerabilities are recognized
CVE-2014-9761, CVE-2015-5229, CVE-2015-7547, CVE-2015-8776, CVE-2015-8778 and
CVE2015-8779. An aggressor with the capacity to answer a DNS question originating from
an influenced item could make the reaction in a way that would cause a product crash.
Regardless of whether the product crash would be deadly to the general capacity of the item
is still under scrutiny. Google has inside exhibited remote code execution in light of this
powerlessness. Assaults that accomplish remote code execution should regularly be
exceptionally modified to a particular application. The potential for remote code execution
inside influenced items stays obscure [1].
Attack Vector
• The DNS intermediary on localhost will ask the assailant the two inquiries over
UDP, and the aggressor reacts with a TC banner to drive customer to retry over
TCP.
• The aggressor reacts once with a TCP reaction of 2049 bytes or more, at that point
powers the intermediary to close the TCP association with glibc resolver code.
This is a basic advance with no solid method to accomplish that.
• The assailant sends back a full assault payload, which the intermediary cheerfully
advances to the glibc resolver customer [2].
Exploitation Scenario

With a specific end goal to abuse this, the assailant can send a truncated UDP A+AAAA
inquiry, which triggers the essential retry over TCP. The assailant reacts with a substantial
answer with a TTL of 0 and dnscache sends the glibc customer a truncated UDP reaction.
Now, the glibc work send_vc() retries with dnscache over TCP and since the past answer's
TTL was 0, dnscache approaches the aggressor's server for the A+AAAA question once
more. The assailant reacts to the A question with an answer bigger than 2000 to actuate
glibc's cradle botch, and dnscache then advances it to the customer. Presently the aggressor
can either endure the AAAA inquiry while [3] different customers are making superbly
genuine solicitations or rather make 20 TCP associations back to dnscache, until dnscache
ends the assailant's association. Since we've met every one of the conditions to trigger another
retry, the aggressor sends back any legitimate A reaction and a substantial, larger than usual
AAAA that conveys the payload (either in CNAME or AAAA RDATA), dnscache hurls this
back to the customer, setting off the flood [4].
Mitigation
Since the helplessness is activated through receipt of a vindictively made DNS reaction, the
accompanying measures may give relief against assaults:
 Tightly control which DNS servers clients are permitted to speak with.
 Configure those DNS servers to restrict reactions to under 2048 bytes for TCP
and 512 bytes for UDP.
 Prevent man-in-the-center assaults between Alcatel-Lucent Enterprise items
and DNS servers by utilizing physical and organize security best practices
 Run a DNS resolver on localhost where the aggressor can't present asset
weariness, or possibly uphold least store TTL to defuse the cat-and-mouse amusement
assault.
Remediation
• A firewall govern might be set up on the client's firewall to square excessively
vast UDP or TCP reaction parcels - a drawback to this firewall decide is that it can
likewise hinder some real movement, for example, DNSSEC.

• A for the most part great relief is to shield yourself with a nearby storing DNS
resolver1, or if nothing else a DNSCrypt burrow.
• Applying framework level patches to the web-server working framework and
system assets.
References
[1]CVE-2015-7547: glibc getaddrinfo. 2016.
[2]"New critical glibc vulnerability | Qualys Blog", Qualys Blog, 2018. [Online]. Available:
https://blog.qualys.com/laws-of-vulnerabilities/2016/02/22/new-critical-glibc-
vulnerability. [Accessed: 24- Apr- 2018].
[3]"A tale of a DNS exploit: CVE-2015-7547", Cloudflare Blog, 2018. [Online]. Available:
https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/. [Accessed: 24- Apr-
2018].
[4]"A tale of a DNS exploit: CVE-2015-7547", Cloudflare Blog, 2018. [Online]. Available:
https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/. [Accessed: 24- Apr-
2018].