Google Engineers Disclose glibc DNS Resolver Vulnerability
Added on 2019-09-19
4 Pages937 Words382 Views
|
|
|
Executive SummaryGoogle engineers published a blog about a vulnerability which was found in all versions ofglibc since 2.9. The post was published on February 16 2016. As per the blog post, the clientside of glibc DNS resolver is prone to stack-based buffer overflow. When multiple bufferoverflows in send_dg and send_vc functions in the libresolve library in GNU C library, endup allowing remote attackers to gain access and cause denial of service or may even executearbitrary 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/AAAADNS queries” along with libnss_dns.so.2 NSS module. Any software may be altered usingthis function with domain names controlled by the attacker or through an attack via man-in-the-middle.
Technical DescriptionVulnerability DescriptionThe GNU C Library is ordinarily utilized for standard framework calls by programs writtenin C and C++. Six vulnerabilities of the GNU glibc library on Linux disseminations havebeen accounted for in February sixteenth 2016 that could enable a remote aggressor toexecute subjective code on a powerless framework. These vulnerabilities are recognizedCVE-2014-9761, CVE-2015-5229, CVE-2015-7547, CVE-2015-8776, CVE-2015-8778 andCVE2015-8779. An aggressor with the capacity to answer a DNS question originating froman 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 itemis still under scrutiny. Google has inside exhibited remote code execution in light of thispowerlessness. Assaults that accomplish remote code execution should regularly beexceptionally modified to a particular application. The potential for remote code executioninside influenced items stays obscure [1].Attack Vector•The DNS intermediary on localhost will ask the assailant the two inquiries overUDP, and the aggressor reacts with a TC banner to drive customer to retry overTCP. •The aggressor reacts once with a TCP reaction of 2049 bytes or more, at that pointpowers 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 cheerfullyadvances to the glibc resolver customer [2].Exploitation Scenario
End of preview
Want to access all the pages? Upload your documents or become a member.