Last September a serious vulnerability was found in the widely used Unix/Linux bash shell this vulnerability was dubbed “Shell Shock” and had been in existence since the beginnings of the bash shell in 1989. The vulnerability was widely publicized and patches were developed and distributed quickly. While the initial round of Shell Shock patches were incomplete, comprehensive patches have been available since October 2014. In theory Shell Shock should no longer be a threat.
In practice, as per the Cisco 2015 Annual Security Report, there are still a large number of systems that have not yet been patched for Shell Shock. Part of the reason systems haven’t been patched is that they are running older unsupported Linux releases for which patches are not available. Unless a server is actively targeted for attack or displaying performance issues, upgrading to an actively supported OS and patching possible threats is often a lower priority for already overworked IT departments.
However as older code is further examined more bugs are found and the possible attack vectors increase. Qualys’ recently discovered GHOST vulnerability is yet another bug found in older code. GHOST uses a buffer overrun in the gethostbyname functions in the GNU glibc library to provide a means for attackers to execute arbitrary code. The security bulletin includes C code for a program that will test for GHOST and outlines how GHOST can be exploited for the Exim mail server.
GHOST dates back to glibc 2.2 (released November 2000) and was fixed in glibc 2.18 (released August 2013), so the fix is already available. All you have to do is upgrade to glibc version 2.18 or newer.
Unfortunately the repaired versions of glibc may not be an option for older OS versions. One problem is that the glibc library is referenced by applications and a change in glibc versions can cause those applications to break. As a result patching glibc involves both upgrading to an OS that supports the repaired glibc library and testing applications to make sure they can function with the newer system and library versions. If the application doesn’t work on the newer system then the application needs to be upgraded as well. If the application is no longer supported and doesn’t function on the new system version then the decision is between how critical the application is to your organization and how serious a security threat you consider unpatched vulnerabilities.
Finding and patching bugs will not eliminate all security threats. Users may select insecure passwords, fall prey to phishing scams, or lose a laptop with cached passwords. If an attacker wants it badly enough they will find a way into your network. Patching security bugs will make it harder for them to succeed and may give you enough notice to block them completely.