Cyber Security Featured Article

The Shortcomings of Patch Management

April 25, 2016
By Special Guest
Tyler Reguly and Lane Thames, Manager of Software Development and Software Development Engineer -

Picture this movie scene: the protagonist walking out of their home and realizing they forgot to lock the door. They turn around and lock the door as the camera pulls back and you see a gaping hole in the wall that anyone could walk through. It sounds like a scene from a surreal comedy but it’s not far from the reality of installing security patches without applying the required remediation steps.

It’s a common mistake among operations teams. The idea that applying a patch resolves a vulnerability is a logical fallacy that too many of us continually apply. It is true, that in many cases, a vulnerability is resolved by the application of a patch but in many cases application of a patch is simply the first step in the remediation process. In a recent survey by Tripwire, 50% of those surveyed indicated that they or their team did not understand that there was a difference between applying a patch and remediating the related vulnerability. That number is too high. There are a number of examples that we can investigate to identify how this mistake is made and to help us recognize what to look for when determining how to fully remediate a vulnerability.

In order to really visualize this, let’s step away from the server room and into your favourite fine dining establishment. Resolving a vulnerability is not unlike baking a cake or creating an amazing new dessert. The first step in the process is to determine the patch that you need to apply and downloading it. This process is akin to a pastry chef finding a recipe and sourcing the ingredients. The next step in the baking process is to combine the ingredients following the rules of the recipe. Anyone that’s ever applied a patch in a complex software environment running the likes of SharePoint or Exchange can relate to this, those prerequisite lists often look just like recipes. When the chef has the ingredients combined and the batter for the cake sitting in the bowl, we’ve got our patches installed. This is where many in operations stop the process. They’ve installed the patch and their work is done. So imagine this, you’re sitting having finished an excellent meal, waiting for your dessert and the chef, himself, appears at your table, placing this bowl of goop, the unbaked batter in front of you.

Now that you’ve thought on that for a minute, are you happy with the result? This is what happens when you simply apply a patch and don’t complete the process. Just as you want the pastry chef to bake the cake and deliver it in a edible state, those in information security want you to complete the vulnerability remediation process to leave systems in a secure state. Now that we’ve got a clear image of the difference between applying a patch and remediating a vulnerability, let’s take a look at a few real world examples.

Let’s talk about two vulnerabilities that required additional steps following the installation of the patch in order to fully remediate the issue. First on the list is Oracle’s TNS Listener Poison Attack, identified by CVE-2012-1675. It is a man-in-the-middle vulnerability that exploits TNS listener registrations. This vulnerability made headlines due to the severity of the issue and has since caused headaches for many administrators and security professionals. Even with all of the media attention and the many technical resources available, including those from Oracle, very few administrators know how to truly protect themselves from this vulnerability. This is not an anecdotal statement. We’ve spoken to many clients who have trouble remediating this vulnerability. In almost all cases, we find that clients have the appropriate version of the database installed, but failed to fully remediate the defect. In this case, having the proper version of the TNS Listener installed is not enough. To fully resolve this vulnerability, administrators must apply a configuration setting to the listener that affects how registrations are handled.

Next on the list is MS15-124, a security bulletin released by Microsoft during its December 2015 “Patch Tuesday”. It is another example where patch installation does not completely resolve a vulnerability. MS15-124 describes the details of an Internet Explorer cumulative update that resolves 30 vulnerabilities and addressed security bugs related to memory corruption, address space layout randomization (ASLR), information disclosure, and cross-site scripting. However, installation of the MS15-124 cumulative update alone does not provide full remediation. It turns out that one vulnerability, an ASLR bypass identified by CVE-2015-6161, requires a little more effort to remediate. Particularly, after installing the patch, administrators must make a few changes to the Windows registry. The details of these modifications are provided in the “Vulnerability Information” section of the bulletin. Without these changes, users are still vulnerable after applying the patch. Similar to the Oracle TNS Listener Poison Attack, we often find clients with still systems vulnerable to CVE-2015-6161 because they only installed the patch and did not observe the details regarding complete vulnerability remediation.  

These are just two examples of an epidemic that is sweeping enterprise security. There’s a disparity in the knowledge that exists between security teams and operations teams and, often, between vendors and enterprises. Unless you’re an expert, these extra steps may not seem clear. Take the original example of the pastry chef, arguably an expert in their field. Swap in a teenager in a home economics class baking for the first time and remove the final step of the recipe that says to bake at 350 degrees for 45 minutes. That teacher may very well eat cake soup as a result and it won’t be the teen’s fault. This isn’t any different from IT Operations.

As technology’s intersection with our daily lives increases, the demand for those in technical roles increases. Mobile computing, the Internet of Things, Industrial Internets, critical infrastructure, intelligent transportation systems, and more... the list of new technology grows on a daily basis. Those dealing with these technology issues are often new to the field and new to their role. They need all the steps in the recipe but they also need to know to look. It’s important that the security industry look to solve this problem set via software and user education. This explanation of the difference between applying a patch and resolving a vulnerability is a small step toward beginning this process, the industry still has a long way to go. 

About the Authors

Tyler Reguly is a Manager of Software Development with Tripwire, and a key member of VERT (Vulnerability and Exposure Research Team), where he focuses on web application security and vulnerability detection. Tyler is involved in industry initiatives such as CVSS-SIG and WASSEC, and has spoken at many security events, including SecTOR and OWASP Toronto. Additionally, he has contributed to the Computer Systems Technology curriculum at Fanshawe College in London, Ontario by developing and teaching a number of security related courses. Tyler is frequently quoted by security industry press and is a prolific blogger.

Vulnerability and Exposure Research Team (VERT). As a member of VERT, Lane develops software that detects applications, devices, and operating systems along with vulnerability detection and management software. He also spends time looking for new vulnerabilities, contributing to the Tripwire State of Security blog, and understanding emerging cybersecurity threats. Lane received his PhD in Electrical and Computer Engineering from the Georgia Institute of Technology and has spent over 10 years working in information technology and software/hardware development. Lane worked for nCircle prior to their acquisition, and continues his research work now for Tripwire.




Edited by Peter Bernstein

Article comments powered by Disqus
Free Subscription