Most software developers use a carefully designed process to handle bug fixes. The process collects problem reports and eventually develops a software patch to fix the problem. A patch is a piece of binary data that modifies the instructions in a program to correct a problem. Most modern computing systems have special software to apply patches to existing software.

The alternative to patching is to reinstall a new copy of the original software. Modern software packages often grow quite large. It is more efficient to distribute a patch, even if it contains several million bytes of data, than to replace a 100-­million byte program.

There are always more problems to fix than resources to fix them. Developers use the process to prioritize flaws, develop fixes, and distribute fixes. A typical process follows these steps:

1. Collect error reports. These may come directly from individual customers, from companies that use the software, or from news reports of problems. In the worst case, error reports may come from national flaw reports, like the Common Vulnerabilities and Exposures database.

2. Prioritize errors and assign for investigation. A team of software engineers reviews the error reports and assigns the highest priority ones to engineers to investigate and to try to fix.

3. The engineer develops a fix for the software problem. This yields a change to the software containing the flaw.

4. Another engineering team reviews proposed bug fixes for release in an upcoming patch. The team selects the fixes to include, and it integrates those fixes into a new patch.

5. Test the patch. A test team applies the patch to different versions of the software and tests them for correctness and stability. The vendor doesn’t want to release a bug fix that makes matters worse.

6. Release the patch. Software engineers package the bug fixes into a patch file for automatic installation. They place the patch on the vendor’s website and ensure that automatic patching software can find and install it.

Many bugs may take weeks or months to work their way through this process. Higher-priority bugs, like those that pose a serious security risk, may be fixed sooner. Given a sufficiently serious bug, the process may only take a matter of days.

In the ideal case, a small number of people in the security community find out about a software security flaw, and the vendor develops a patch for it. The general public doesn’t really learn about the flaw until the patch appears. Then a race begins between black-hat hackers who want to use that vulnerability to attack systems and end users who want to patch their systems.

Many end users fail to patch their computers, even when patches are available for known vulnerabilities. FIGURE 3.18 summarizes a vendor’s typical patching experience. Shortly thereafter, black hats have reverse-engineered the patch to figure out the vulnerability, and they construct an exploit: malware that uses the vulnerability as an attack vector. The black hats then search out and attack the unpatched systems.

Using network scanning software, black hats search the internet and identify unpatched computers. The exploit software attacks those systems. Matters have improved in recent years because the patching process has become more efficient, reliable, and automatic. Technophobic users can set their computers to update software automatically. Even so, countless computers go unpatched for weeks or even years.

Each vulnerability represents a race between the white-hat and black-hat communities. White hats, including responsible security researchers and vendors, try to find security flaws and deploy patches before exploits arise. Black hats try to identify flaws and construct exploits before the patches appear. The ideal goal for a black hat is to construct a zero-day exploit: one for which no patch yet exists.

If matters progress as shown in Figure 3.18, then the vendor releases a patch and the software enters the Patchable state (FIGURE 3.19). If the user immediately patches the software, it returns to the Hardened state. Otherwise, it moves to the Vulnerable state when an exploit appears.

The software remains vulnerable while an exploit exists and the software remains unpatched. We call this the window of vulnerability: the period of time during which a system is unprotected from an exploit. As long as the software remains unpatched in the face of a possible exploit, it is vulnerable to attack.

If, however, we face a zero-day exploit, then the software moves to the Unprotected state. The user has no choice but to be stuck in a window of vulnerability until the vendor releases the patch. The only alternative is to stop using the vulnerable software.

The Unprotected state could also arise when we install new software from a DVD or other distribution media. The distribution disk may contain an older version of the software that lacks the latest patches. Thus, the newly installed software may start out in the Unprotected state.

This was a particular problem with Windows XP, the Windows version introduced in the early 2000s. Various estimates in 2005 suggested that an unpatched Windows XP machine would only last a matter of minutes before being attacked on the internet. When a user installed Windows XP from a distribution DVD, the system would remain Unprotected while it connected to the internet and downloaded the patches needed to reach a Hardened state.