Bugs Versus Vulnerabilities
Theo de Raadt, the project leader of OpenBSD—a free UNIX-like system with a first-rate security record—is quick to take issue with the idea that they have people looking for security holes. His attitude is that the only difference between a vulnerability and a bug is that someone has found a way to maliciously take advantage of one, but not the other. The OpenBSD code-auditing process is not there to hunt for vulnerabilities; its purpose is to hunt for bugs. Ignoring a bug because you don’t know how to exploit it is a good way of creating more problems for yourself later.
The arbitrary distinction between a bug and a vulnerability gives many projects a false sense of security. A bug is a bit of code that does something other than what the author intended. If the code does something unintended, it may be possible for an attacker to use this unintended behavior to advantage—at the very least, causing a crash or some kind of data loss.
The first step in any project’s security process is finding a potentially exploitable bug. If the project has a code-review program, or someone happens to be modifying a section, the bug could be discovered internally to the project. It’s more likely, however, that someone will find the problematic behavior in the field. At this point, a developer will receive a bug report. The amount of information provided can vary hugely:
- The best case is only possible for an open source project; namely, that the user who found the bug reproduced it in a debugger, isolated the cause, and found a way to fix it.
- The most likely case is the same for all kinds of software: The user provides some details of what he or she was doing at the time, which may or may not be enough information for the developer to reproduce the bug.
Reported bugs usually go into a bug-tracking system of some kind. Once a bug has been reproduced, some decisions need to be made. The first is the priority with which a fix is sought. In a community-developed project, the bugs that are fixed first are likely to be the ones that are encountered often by the developers themselves. In a commercial project, or a more organized community project, priorities are assigned by a leadership team.