Back in the days before television informercials, there were ads asking “How many times has THIS happened to you?” What usually followed was some common problem with an outlandish solution that didn’t work. All it cost you was $9.95 shipping and handling! (“Call before midnight and receive this free set of plastic steak knives that look real!”)
Fast forward to today’s world of cybersecurity: what do you do when the solution to your problem – say, a binary patch that is supposed to fix a known flaw in an application’s code – doesn’t solve the problem. Or worse, it breaks your application? The financial and operational consequences are substantially higher than the $10 you’d lose from trying to fix your leaky faucet with a bad TV product.
Yet, that’s what exactly what has occurred with the two most recent Oracle critical patch updates. In both the April and July 2018 CPUs, patches designed to fix known CVEs were later found to be easily by-passed or applying them required significant development work to avoid breaking an app’s functionality.
The April 2018 Oracle quarterly Critical Patch Update (CPU) included a fix for the critical WebLogic server vulnerability CVE-2018-2628 that carried a high-risk vulnerability rating. One day later after the CPU’s release, multiple users on GitHub released proof of concept (POC) exploit code against this flaw. Soon after, reports indicated increased scanning activity for vulnerable, unpatched servers.
The July 2018 CPU includes one patch that requires a rebuild of an application and other patches that run the risk of breaking functionality. The fix for the most critical Java SE vulnerability – CVE-2018-2938 – removes the vulnerable component (Java DB) from the JDK, requiring users of this component to manually obtain the latest Apache Derby artifacts and rebuild their applications.
Another component of the July CPU introduced new deserialization controls in the JDK that limit the object creation phase of deserialization. These new security controls may break reflective frameworks that make use of JDK-internal APIs. These security checks can be disabled to allow these reflective frameworks to work normally, but by disabling these security checks, attackers can potentially exploit this vulnerability.
For teams who still rely on making source code changes, rigorously testing physical patches is one way to avoid the problems outlined above. For Waratek customers, though, applying a real-time patch using the JIT compiler rather than making source code changes avoids the risk of breaking an application or backwards compatibility issues.
You can learn more about how Waratek can help patch and secure your applications with no downtime or source code changes by requesting a quick demonstration. No infomercial required.
