The latest security vulnerability splashed across the headlines may have drawn attention more for its brand association than its bite. CVE-2016-6662, a vulnerability in the widelyused mysql database application, can be exploited via SQL injection attack, or by an attacker with valid credentials, either locally or over the Web via phpMyAdmin, for example.
The attacker only requires a file-system writing permission at some level. The rapid and intense news coverage and water-cooler discussions of the vulnerability also point to a bigger problem: Companies are increasingly anxious and concerned about vulnerabilities, highly sensitized by massive and relentless growth of the vulnerability headache.Remember the eight Symantec vulnerabilities recently uncovered andthe failed Sophos patching two weeks ago?
The MySQL vulnerability was publicly disclosed earlier this week by independent security researcherDawid Golunski, who discovered and reported it to Oracle back in July. As of this time, Oracle has not yet released a patch for this security hole, although other vendors affected by the flaw have already patched their systems. According to some experts, the vulnerability is very easy to stop and limited in scope. Others call it critical.
Whether hype or high-priority, if this plays out like other zero-day sagas, customers will berate their vendor, clamor for a patch, settle down when it’s finally released and then…do nothing. Because the hard truth is that most companies are severely behind in patching system vulnerabilities, and this is unlikely to change soon. Patching and patch management is one of the most contentious and burdensome IT issues―it is costly, can cause system conflicts and disrupts ongoing business activities. This creates tension between IT teams, security departments, and management. And the problem will only grow worse.
SANS 2016 State of Application Security Report
Download Now
Software vulnerabilities are business vulnerabilitiesAs software becomes more advanced and complex, it is impossible for programmers to eliminate all potential weaknesses in their code. An individual operating system or application may have hundreds of new vulnerabilities each year, each of which needs to be patched. The worst kind of vulnerability is one created deliberately, though maybe not knowingly, by poor programming, usually related to security applications. Such vulnerabilities are derivatives of flawed programming practices used in order to overcome compatibility issues. For example: Security applications that inject 64-bit DLLs into 32-bit applications, or products that keep restarting their injection threads, unsigned after their first failureand until they overcome a compatibility issue.Moreover, almost every program or application has a different frequency and patching method.
Recently, theCISOof a customer looking for preventive augmentation of its antivirustold me: “We are constantly patching. It takes us four weeks to test and roll out, and as soon as a patch is ready to roll, we decide what the next sequence of patches will be.” What he left out is that, in addition to this, it can take the vendor several weeks to provide the patch, leaving the company vulnerable for an extended period.
These flaws become a playground for hackers to exploit. Patches fix a vulnerability, and, as a result, each patch defines and then publicly exposes that vulnerability. It usually takes hackers only a few days to release an exploit attacking that hole. In fact, this is the reason given by Golunski for disclosing the MySQL vulnerability: The public release of other vendor patches exposed the vulnerability for exploit, yet no official Oracle patch is available. Beyond their risk implications, these vulnerabilities and the overhead they create are a business impediment.
Zero-day attacks that use new, unknown vulnerabilitiesare constantly unveiled. Symantec’s 2016 Internet Security Threat Report found that the number of zero-day vulnerabilities discovered averaged more than one a week in 2015, double the number in the previous year. Zero-day vulnerabilities command high prices on the black market, and discovering unknown vulnerabilities and figuring out how to exploit them has become the gold standard for advanced attackers. Your system will still be vulnerable to zero-day exploits regardless of the amount and frequency of patching.
Even worse, attackers can exploit zero-day vulnerabilities that reside in the security products themselves. The vulnerable code is, in many cases, part of core kernel components shared between many versions of the product. That was the case with CVE-2016-2208 in Symantec products. Exploiting vulnerabilities in such low-level and high-privileges libraries give the attacker immediate and full control of the system. These types of vulnerabilities have been found in top security products, including Comodo, ESET, Kaspersky, andFireEye.
The problem with patchingThe existing defense paradigm, whereby a security product needs to have prior knowledge―be it database, signature, rule, policy, learning, or AI algorithms―does not effectively prevent evasive malware and advanced persistent threats from exploiting unpatched or newly-found-in-the-wild security vulnerabilities. Software vendors, as they become aware of new vulnerabilities, work rapidly to remediate them. This results in a continuous stream of security patches sent to their customers. As a result, we keep racing in an infinite, tiring, Sisyphean pursuit.
Patching software in an organization is a complex task. It requires careful planning, execution, and validation. In some cases, it involves halting and rebooting a machine, thus interfering with employees’ work or business processes that run on a server. Sometimes the patch itself causes a conflict with other applications running on the machine. For all of these reasons, patching requires a lot of attention and careful coordination between IT and security personnel. And the bad guys sit back and laugh as they watch companies chase their tails, patching, patching, patching.
In short, software vendors are constantly creating an immense number of new patches to cover their vulnerabilities. Furthermore, security and IT teams face an endless (and ever-increasing) burden of executing those patches. The result is that patching happens intermittently―if at all―because IT and business operations cannot tolerate the potential operational impact security patching represents.
More patching is not the answerThe recent MySQL vulnerability may not pose a serious risk, but the reaction to it highlights the concern that underscores a spiraling problem for many organizations. As unpatched security vulnerabilities within an organization snowball, the impact on IT and business operations by exploits of these unpatched vulnerabilities increases exponentially. Not only in operational uptime, performance, and availability, but eventually in brand damage, regulatory fines, penalties, and legal actions that hurt the company on a largeand long-term scale. Added to all this is the potential theft and loss of intellectual property and competitive advantage in the marketplace.
More patching is not the answer. Neither is hoping that software vulnerabilities will simply go away. Even if companies could keep up with every