A Vulnerability Management (VM) program is commonly defined as the “cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities” . According to Gartner’s report , the purpose of the remediation phase is to harden the environment, prior to eliminating the vulnerability, by using desktop and network security tools, while the mitigation phase role is to eliminate the root causes of the vulnerability by applying a patch to the system.
Although the remediation phase might be viewed as a mere interim phase en route to the ultimate solution by applying a vendor patch, in reality the remediation phase is a crucial phase in running a successful Vulnerability Management program.
Remediating advantages
The advantages of remediating are of three main aspects: availability, fine-grained control and decoupling from the vulnerable system.
Remediating patches are usually more available than vendor patches as they are released earlier as some vulnerabilities remain unfixed by the vendor for years. A recent example for it is the recently published proof of concept code exploiting a 4-year-old unpatched vulnerability in Oracle databases.
Remediation patches are focused in solving the security vulnerability – nothing more, nothing less. Therefore, they give the app owner very granular control over the remediation of the specific vulnerability. In comparison, vendor patches often include some additional code such as changing or adding other application functionality, which might make the deployment of the solution infeasible. In other cases, later vendor’s software updates contain a regression problem and accidently remove the protection offered by the former patch, thus rendering the application vulnerable again, unbeknownst to the application owner.
The final advantage is decoupling, due to the fact that remediation patches are installed on a separate environment and as a result does not affect the application in an undesired way. For starters, applying a remediation patch does not require the take down of the patched system as vendor patch often do. Since patches are sometimes found to be incomplete this may mean a couple of application restarts per a single vendor patched vulnerability. In extreme cases a faulty vendor patch code is not only incomplete but may even expose the application to some new vulnerabilities.
Case study: PHP has traded a DoS vuln for a Remote Code Execution one
An ironic, yet not uncommon, is a vendor patch that actually reduces the security of the application rather than increasing it. One example of such has just occurred earlier this year with the popular PHP web server environment.
The original CVE (Common Vulnerabilities and Exposures) description (CVE-2011-4885) states that certain versions of PHP server are susceptible to Denial of Service (DoS) attack due to a weakness in the way they handle HTTP parameters. The vulnerable implementations would store the HTTP request’s parameters value in an array. The array’s its index is resolved by applying a hash function on the parameter name, without taking hash collisions into consideration. An attacker could exploit that vulnerability by creating an HTTP request that contains many parameters which their index is resolved to the same array’s cell. In such case, performing operations on the array become very inefficient and eventually may cause a denial of service due to excessive CPU consumption.
The CVSS (Common Vulnerability Scoring System) score assigned to the vulnerability by NIST (National Institute of Standards and Technology) was 5.0, which is considered to be of “medium” severity.
PHP programmers decided to fix the issue by limiting the number of allowed parameters within an HTTP request to one thousand. The limitation solves the DoS issue, as even if all thousand values are mapped to a single array’s cell, it doesn’t put too much of a burden on the server’s CPU. However, the patch code was buggy in the way it handled a certain type of parameters, thus introducing a new vulnerability (CVE-2012-0830). The new vulnerability allowed a remote attacker to execute arbitrary code, and received a CVSS score of 7.5 which is considered to be “high”. Ironically, by applying the patch on a vulnerable system, made it less secure than it was before.
Exploring bad patches problem’s magnitude
In order to estimate the actual magnitude of bad updates and patches, we had analyzed the NIST database and searched for patching problems indications in the CVE description. To do so we had used the NIST site’s internal statistics functionality on the following indications:
• Regression problems when a previously patched vulnerability is reopened by some update are often indicated by “NOTE: this vulnerability exists because of a CVE-…. regression.”
• Incorrect Fix problems are often indicated by: “NOTE: this vulnerability exists because of an incorrect fix for CVE-….”
• Incomplete Fix problems are often indicated by “NOTE: this vulnerability exists because of an incomplete fix for CVE-….”
The results show that patching problems are not anecdotal as they account almost one percent of all vulnerabilities.
Figure 1 – CVEs introduced by patches problems
Bear in mind, that this is only a lower bound, as some vulnerabilities may have stemmed from patching and updating problems but did not include the proper indication in the CVE description. This may also explain the rise in patching vulnerabilities throughout the years, as it more likely to be attributed to more elaborate CVE descriptions rather than to decline in patches quality.
Patch is a dish best served hot and externally
Summing up, a pragmatic approach to vulnerability management must include some compensating security controls in the form of an external security system that allows remediating vulnerabilities with hot patching. By doing so, the application owner is not be forced to choose between staying vulnerable or going through an immediate and costly patch update cycle, but could have an immediate remedy by applying a hot patch on the external security system protecting the application and apply the vendor’s patches in due time.
