Today a critical vulnerability was found in the GNU C Library (CVE-2015-7547), which is widely used in most Linux machines, the vulnerability is being compared to a similar one from the year prior in 2015 known as “GHOST vulnerability”(CVE-2015-0235)
The exploit was found thanks to some engineers over at Google, the engineer at google noticed his SSH client segfaulted every time they tried to connect to a specific host. Google of course followed up with a support ticket to start an investigation into the matter. Upon doing so Google found that the glibc maintainers had been alerted of the issue back in July 2015, but they were not sure of a fix had been started, so Google set out to patch the bug and learned Florian Weimer and Carlos O’Donell of Red Hat had also been looking into the bug. Through this they were able to collaborate to create a patch for this bug.
At this time the patch can be found; here
It is highly recommended that everyone upgrade immediately regardless if you’re on an older machine, as the issue affected all the versions of glibc since 2.9.
To quote Google them self, here is the technical information regarding this exploit.
Technical information:
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.
Exploitation:
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.
As you can see in the below debugging session we are able to reliably control EIP/RIP.
(gdb) x/i $rip
=> 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req
(gdb) x/a $rsp
0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042
When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril!
Failed exploit indicators, due to ASLR, can range from:
- Crash on free(ptr) where ptr is controlled by the attacker.
- Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address.
- Crash reading from memory pointed by a local overwritten variable.
- Crash writing to memory on an attacker-controlled pointer.
Any of our current clients on our shared platform need not to worry as we’ve already taken care of patching this bug. Any clients who are utilizing dedicated servers or cloud, can contact support if you need assistance with patching this.
– Code Blue Hosting Team