Last month the glibc vulnerability received a lot of media coverage. What makes this vulnerability so impactful, and so sparked the media coverage, is that the glibc library is used in practically every Internet facing application. This library is present in almost all distributions of Linux and is used widely in hardware like VPN switches and routers. Given this footprint, a very large swath of applications that had not updated to later patched versions are potential targets for attacks.
Let’s revisit what happened: On February 16, 2016, two researchers from Google reported a serious issue in the glibc library (v2.9 onwards) and more specifically in the function getaddrinfo(). Any software using this function is vulnerable to an attacker controlled DNS Server, to an attacker controlled domain name or to a man-in-the-middle attacker. Coincidentally, two researchers from Red Hat had been investigating this same issue since July 2015. A patch for this vulnerability has been released through version 2.23 of the glibc library. This patch was released on Feb 19, 2016. Here is the timeline for the glibc library.
What’s even more interesting is that this glibc vulnerability found its way into the official glibc library release of November 13, 2008. This is a case of a zero day vulnerability existing in the wild for almost 8 years! This glibc zero day vulnerability is symptomatic of the kind of vulnerability the most sophisticated hackers exploit in order to seize control of high value victims such as a web facing data center application that regularly accesses high value enterprise crown jewels or confidential information such as credit card data, SSN Information, etc. Everything in the target machine and perhaps in the other machines reachable from the victim machine is at serious risk.
We decided to explore this vulnerability further to investigate if our product, Virsec Platform, would detect an attack built on this zero-day vulnerability without any prior knowledge. For this purpose, we needed to do just enough to exploit the vulnerability in the lab. Exploitation of the glibc vulnerability is possible but relatively difficult. We had to build a “vulnerable” application that uses the function getaddrinfo(). We also had to build a “malicious” DNS Server that would dispatch the exploit payload on demand.
Creating a glibc Exploitation
In order to exploit the vulnerable code, we started out by shutting off ASLR but not NX such that in the first pass we could trampoline to our static “helper” library easily. Not being malicious adversaries ourselves, we saw little reason to continue pursuing a ROP Chain based exploitation path instead of using our “helper” library. If we really were malicious adversaries, we would have continued on to develop a ROP Chain based attack.
In the victim machine, we changed the nameserver setting such that DNS queries would be directed to our malicious DNS Server. As soon as this vulnerable application crashed, we had a back trace with the detailed call stack. Sure enough we found that when the function _nss_dns_gethostbyname4_r() unwound its stack, it crashed. We then proceeded to establish the call stack for the scenario in which the application would not crash. This helped to establish that the function send_vc() managed to corrupt the stack of _nss_dns_gethostbyname4_r(). A few steps later, we found we had to preserve some other pointers on the stack of _nss_dns_gethostbyname4_r() otherwise some intermediate functions between the send_vc() and _nss_dns_gethostbyname4_r() calls would crash. This experiment helped us create the “just right” exploit payload. Once that exercise was over, when the stack of the function _nss_dns_gethostbyname4_r() unwound, we were able to successfully trampoline into our malicious “helper” library. Using netcat and establishing a connection to the victim machine and by trampolining to a bind shell call from the helper library, we were able to establish a remote shell into the target machine. We effectively achieved root access on the victim machine. Consequently, a lot of damage could be wreaked on the said victim machine. We could potentially delete files or add more code on this victim.
Prevention with Virsec Platform
At Virsec, we subscribe to the philosophy that a truly effective security solution should not rely on a signature arising out of some form of knowledge base built from a prior attack –be it heuristic, behavioral or through honeypots. Our goal is to build a solution of high prevention caliber that should be able to detect an attack in real time as soon as possible and stop it from taking hold. So how did our product hold up on this glibc “zero-day” exploit? As expected for a technology we tout as practically 100% accurate for zero-day binary protection.
As the stack of the function _nss_dns_gethostbyname4_r() unwinds and tries to return to the adversary code instead of the function _res_hconf_init(), Virsec Platform spots the attack, and sends out its alerts (to the SecOps team). This would prevent the remote attacker being able to seize control of the application and use it to establish say a remote shell on the victim machine. Virsec Platform would not have needed any prior knowledge of this vulnerability and in fact could have alerted the SecOps team that a serious vulnerability existed – even 8 years ago and in real time.
Implications of Vulnerabilities
Recently released data in Dark Reading suggests that in 80% of the most common attacks against healthcare organizations, the root cause of the attacks were vulnerabilities that were older than three months. We know this is the case for other industries as well. It’s imperative that as a security industry we find a fool proof way to close the window of exposure to these insidious vulnerabilities. At Virsec, we think we’re on to something.
