A quite serious bug for Unix/Linux users was discovered days ago by a Google engineer, almost accidentally.
CVE-2015-7547 is a critical vulnerability in glibc affecting any versions greater than 2.9. The DNS client side resolver function
getaddrinfo() used in the glibc library is vulnerable to a stack-based buffer overflow attack. This can be exploited in a variety of scenarios, including man-in-the-middle attacks, maliciously crafted domain names, and malicious DNS servers.
What we've done
The ElasticHosts host and control servers have been patched for this bug fully.
However, we cannot patch customer servers - and we strongly recommend that those who may be affected update your servers as soon as possible.
What you need to do
For those who use Unix/Linux OS, it's paramount to update your servers as soon as possible. Just update your packages, install them and reboot the servers. E.g:
For Ubuntu/Debian (as root or sudo)
For CentOS (as root or sudo):
If you are a developer and have apps compiled with a vulnerable glibc version (2.9. and above) those will have to be recompiled with an updated version of the library.
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_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. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this Proof of Concept, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact.
(From Google's security blog post)