Thursday, February 5, 2015

Security Basics: What is a Zero-Day?

Recently, Adobe Flash Player has been in the news for having their third zero-day vulnerability exposed within the past few weeks. This has caused a bit of hysteria in the security community, but many non-security professionals may not recognize how important these vulnerabilities are.

First, what is a vulnerability? A vulnerability is a weakness which allows an attacker to cause harm or damage to an information system. So what makes a vulnerability into a zero-day?

A zero-day vulnerability is the same thing except that the weakness was previously unknown by the software vendor, and therefore no patch has been released. On the opposite side of the gun, you may hear this referred to as a zero-day attack, which is similar, but defined as the exploitation of a zero-day vulnerability.

So why don't the software vendors know about the problems in their software? They made it, so they should know, right? Well, yes... and no. A company usually tests, re-tests, and re-tests again many times over to ensure that everything runs smoothly. However, usually software programs like Adobe Flash Player have so many lines of code and so many possible ways to exploit them that it can be tough for a small team of security experts to analyze every possible vulnerability that a large community of attackers could find.

Let's make an analogy that many gamers will be able to relate to. When a new video game is released, there are almost always issues with the game that make something too easy or not work in the fashion that the developers imagined. When we exploit the bugs to gain an advantage, it's often referred to as "cheesing" a part of the game. This occurs because there are so many lines of code to check and double check that sometimes a hole will be missed by a group of game testers.

Similarly, when software programs are released, it is subject to similar quality assurance tests to be sure that there are no issues with the code. However, the teams that are checking for bugs in software are nowhere near as large as the consumers who use the program at a massive scale. Almost always, a bug will be found after its release.

There are many reasons that the bugs will not be found.

  1. Deadlines are set too aggressively and quality assurance time is cut to satisfy them.
    • Many companies will release their "minimum viable product." In other words, if it seems to work and it will generate sales, get it on the shelf.
  2. The bug is in a function of the program that is rarely used.
  3. Software is not properly tested for the scale in which it is released.
Sometimes the bug will be nonchalantly patched with no major issues to end-users. However, some bugs will cause major issues for the software, giving a user access to parts of the program that they aren't meant to have access to. If the developer didn't previously know about this hole in their software, it is labeled as a zero-day vulnerability.

This is the third time in 2015 that a zero-day vulnerability was found in Adobe Flash Player. While it is now patched, it has caused some uproar in the security community about the integrity of the commonly used program. The security jargon is that the exploit has the ability to crash and potentially allow an attacker to take control of an affected system. This is caused by an address space layout randomization (ASLR) mitigation bypass. ASLR is meant to protect the software from buffer overflow attacks, but was still successfully exploited due to memory-management issues.

If you have any questions about zero-day vulnerabilities, please comment below and I'll address them!