{"id":80,"date":"2016-02-17T03:53:44","date_gmt":"2016-02-17T03:53:44","guid":{"rendered":"http:\/\/www.urolime.com\/blogs\/?p=80"},"modified":"2021-03-09T21:23:39","modified_gmt":"2021-03-09T15:53:39","slug":"critical-vulnerability-in-glibc-getaddrinfo-cve-2015-7547","status":"publish","type":"post","link":"https:\/\/www.urolime.com\/blogs\/critical-vulnerability-in-glibc-getaddrinfo-cve-2015-7547\/","title":{"rendered":"Critical glibc vulnerability CVE-2015-7547"},"content":{"rendered":"

What’s the glibc getaddrinfo\u00a0vulnerability?<\/h2>\n

Red Hat has updated details<\/a> on the vulnerability.<\/p>\n

A stack-based buffer overflow was found in the way the libresolv library performed dual A\/AAAA DNS queries. A remote attacker could create a specially crafted DNS response which could cause libresolv to crash or, potentially, execute code with the permissions of the user running the library. Note: this issue is only exposed when libresolv is called from the
\nnss_dns NSS service module. (CVE-2015-7547)<\/p>\n

The technical explanation about the exploit<\/h2>\n

This is best provided by Google’s security team<\/a> themselves.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Who’s vulnerable?<\/h2>\n

Quite a lof systems are potentially vulnerable to this exploit:<\/p>\n

All versions of glibc after 2.9 are vulnerable. Version 2.9 was introduced in May 2008.<\/p>\n