Chances are pretty good you’ve heard the term zero-day vulnerability. The term conjures up images of post-apocalyptic landscapes, where technology has either hit a singularity-level madness or has reverted back to the days of CRT monitors and green screens. Max Headroom has returned and sand is the new currency.
Truth be told, zero day is not even remotely as ominous. It is, however, quite serious. In fact, of all the known vulnerabilities, zero day can often pose the most risk. Why? The reason is in the very definition.
What are zero-day vulnerabilities?
A zero-day vulnerability is a flaw in a piece of software that is unknown to the programmer(s) or vendor(s) responsible for the application(s). Because the vulnerability isn’t known, there is no patch available.
In other words, the vulnerability has been discovered by someone who isn’t directly involved with a project. The term zero day refers to the days between the time the vulnerability was discovered and the first attack against it. After a zero-day vulnerability has been made public, it is then referred to as an n-day vulnerability.
Here’s how the zero day timeline works:
- A person or company creates a piece of software that includes vulnerability but is unknown to those involved with programming or distribution.
- Someone (outside of those responsible for the software) discovers the vulnerability before a developer has a chance to locate or fix the problem.
- The person who discovers the vulnerability creates malicious code to exploit the vulnerability.
- The exploit is released.
- Those responsible are informed of the exploit and patch their software.
- The vulnerability is no longer considered a zero day.
- The patch is released.
Most often, exploits against a zero-day vulnerability are very rarely discovered right away. It can often take days or months before these flaws are found which is what makes these types of vulnerabilities so dangerous.
What can you do about zero-day vulnerabilities?
There’s not much you can do as an admin or user. The best possible scenario is to never use a .0 release of the software. This is often common in the Linux community, where many users won’t install a .0 release of a distribution. Instead, they’ll wait for the .1 release (such as Ubuntu 19.10.1). By avoiding initial releases, you might be safe from at least any undiscovered zero-day vulnerabilities within the first offering. That doesn’t mean the .1 release will have any/all zero-day vulnerabilities patched. If there are any, they could go undiscovered even until the next major release. On a regular basis, we hear of new vulnerabilities found in software that has been around for quite some time.
As a developer, the best thing you can do is recruit as many beta testers as possible. This is where open source software has an edge over proprietary. With the source open to the public, anyone can vet and test the code. Also, beta open source software is generally released to the public so anyone can test. Proprietary software, on the other hand, often doesn’t release betas to the public (of course, there are exceptions). When an application has a limited amount of beta testers, fewer bugs are discovered, which leads to a higher probability of zero-day vulnerabilities.
So in the end, users should hold off on adopting brand new releases and developers need to test, test, test before releasing to the public.
Finally, one thing you can do is make sure to submit bug reports to developers and companies. Bug reports are a great way for programmers to resolve issues with their software. And you never know, that bug you submit might well lead to the discovery (and subsequent patching) of a zero-day vulnerability.