The Linux glibc Exploit – What You Need To Know
iSpeech
So the Internet exploded this week with news of a pretty serious glibc exploit, something that everyone pays attention to as every Linux server uses this library and in some cases it can yield remote code execution.
In basic terms the glibc DNS client (libresolv) is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used and plenty of stuff could trigger the exploit including SSH, sudo, curl, PHP, Rails and more.
[adsense size='1']
The bug was actually reported last July here – In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer (CVE-2015-7547) but was marked as ‘P2 Normal’ priority – which is clearly not very important even though this is a classic buffer overflow which could be exploited remotely.
Windows, OS X and Android devices are not vulnerable as they use different libraries. uClibc for example had this same bug fixed 6 years ago.
Technical Details
It was reported publicly by Google, here’s the technical summary:
[adsense size='3']
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.
Source – CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow
[adsense size='4']
Most actual exploit vectors are covered by protective technologies like ASLR (good discussion on Reddit) and non-executable stack protection, but there’s still a lot of potential and this has been in the wild for 8 years (since 2.9) – so it’s pretty likely the bad guys have jumped on it long ago.
Gloss