Zero-day security threats constitute a critical imperative driving software development towards liquid software (i.e., continuous updates).
First, let’s be clear about terminology. When we hear about zero-day vulnerabilities, zero-day exploits, and zero-day attacks, the zero is referring to the number of days that will elapse between the moment a software developer learns of a given vulnerability, exploit, or attack, and the moment that problem is disclosed to the public. So, a 30-day vulnerability will have been reported to a software developer thirty-days before being announced publicly. That’s a month-long window within which this type of issue can be mitigated.
It’s a Black and White Situation
Zero-days also raise ethical questions related to cybersecurity and the distinctions we make between Black Hat and White Hat hackers. The former are typically evildoers out for personal gain, while the latter are on a mission to find vulnerabilities for companies to patch before they can be exploited. Typically, we want our vulnerability researchers to be White Hats – professionals who use their talents for the good and honorable purpose of identifying vulnerabilities and offering solutions for them and the time necessary to fix them.
A vulnerability window is the time between when a vulnerability becomes known and is exploitable and the moment it is patched. It’s a given that such windows will, more often than not, be greater than zero, here’s why: White Hats will alert companies about vulnerabilities and wait for a fix to be released before publishing information about what they have found. These are non-zero day vulnerabilities. Black Hats begin exploiting vulnerabilities as soon they discover them. These are zero-day vulnerabilities.
Once a vendor is in the know about a vulnerability, their objective is to release patches or updates quickly, working to keep the vulnerability window to as limited a period of time as possible. Naturally, vendors always prefer to resolve vulnerability problems before information about them becomes public knowledge (i.e., to have a zero or negative vulnerability window).
But here’s the zero-day dilemma: There’s a huge marketplace for zero-day detection and reporting. Generally, buyers don’t have any of our best interests at heart and are willing to pay significantly more for zero-day information than those who are looking out to protect our systems. As you might imagine, then, most vulnerabilities are identified by Black Hats who are highly motivated to find and rapidly exploit the weaknesses they uncover. From there, it’s a race against time. The faster a software vendor can issue a patch, the less damage will be sustained during an attack. It’s a reactive, rather than proactive strategy. And obviously, every malicious cyberattack is zero-day because, if it’s being done for malignant purposes, the attacker has no interest in notifying the vendor.
It Gets Worse
Meltdown and Spectre are two critical vulnerabilities that were found at the start of 2018 to exist in most modern CPU architectures, including Intel, AMD, IBM POWER, as well as some ARM-based microprocessors. The latter is a zero-day enabler and is believed to have contributed to a significant spike in zero-day attacks.
Meltdown focuses its attention on breaking the insulation between user applications and the operating systems on which they run, by allowing a rogue process unauthorized access to all memory and then exploiting some optimizations in the processor threads. Bad as this is, however, protection against Meltdown can be achieved by supplying more context to running threads and making sure that this context is identifiable and used to provide additional isolation. This process – known as collaring or marking the threads – permits us to determine where a data request is originating, thus making it easier to know whether a particular request is trying to get to a place where it’s not allowed to be.
At the beginning of this year, there was much more chatter about Meltdown than there was about Spectre, because Meltdown represented a clear and present danger. It was practically a classroom example of how, in Javascript, one can hop from application memory straight into operating system memory and then mine all manner of personal data, including passwords. Scary stuff! But thanks to intrepid researchers, processor manufacturers have since released fixes for all of their operating systems, and threat of Meltdown has been mitigated.
Spectre is different. Early on, it received less attention than Meltdown because it’s harder to exploit. Nevertheless, it’s a pernicious vulnerability that uses a processor performance optimization known as speculative execution. This means that the processor will try to guess how software should operate at certain junctions of execution logic.
This can be exploited if an attacker can examine the logic embedded within a given piece of software code and determine which of a set of branches a processor will speculatively execute most of the time without checking other options. Once this has been accomplished, an attacker can structure a request for a particular behavior in the same way the processor executes IF logic. From this knowledge, an attacker can guess how the process will work and then make assumptions about certain states of memory. If those assumptions are correct, the attacker can infer what is in the memory and where it resides, and thereby gain unauthorized access to private memory sectors of otherwise secure information. By definition, Spectre can be used as a zero-day exploit. There is no way to write software in such a way that it will be protected from this type of speculative execution attack.
The only true protection against this would be to remove any possibility for speculative execution within processors. That’s not going to happen, however, because it would set back processor performance advancements by at least a decade. Processor vendors have been thinking about ways to make speculative execution a little less predictive – which might make it harder for attackers to make assumptions about behavior – but that’s hardly a solution to Spectre and the class of vulnerabilities it represents.
Beat ’em to the Punch
So, what’s the answer? Speed.
As zero-day vulnerabilities increase, and the knowledge of them spreads across the internet and the Dark Web, there will only be more bad actors ready to exploit our systems. Hackers are always going to figure out how to worm their way into our systems. It’s what they do. It’s what they’ll always do. It’s how they get rich.
Liquid software (continuous updates) is all about accepting the fact that there is no protection. There’s only reaction. There’s no faster way to react than through liquid software. Even so, is it possible that liquid, continuous updates will fail? Of course. And when that happens, a rapid update will be required to fix what’s been screwed up. Regardless of circumstance, the faster the response, the better and more protected our software will be.
