When Should You Fix a Bug?

Posted by Keith McMillan

February 12, 2008 | 3 Comments

Slashdot is running this article on a flaw found in OpenBSD’s implementation of their pseudorandom number generator (PNRG). This number generator is used by the implementation of a number of network services on OpenBSD, and from there its found its way into a number of other *NIX implementations, including Darwin/MacOS X, FreeBSD, and NetBSD. Most of the implementations other than OpenBSD have committed to fix this bug, although Apple isn’t committing to when. Knowing what “random” number is going to come up next permits some exotic exploits that allow an attacker to compromise security. The question at hand isn’t whether this fault exists, it’s how important is it.

OpenBSD’s maintainers have decided that the bug is academic, and doesn’t represent a real enough threat to fix. This puts the debate squarely into interesting territory for me. I’m a pragmatist, and I think that the development activities you perform (and this includes fixing a bug) have to be related to their real value. I classify a bug in the category of “risk”, which means I use a two-part formula to determine how important it is to address.

Although many professionals don’t realize it, risks (and this includes bugs) have two dimensions, severity and probability. Probability is frequently given short shrift, and the focus is all on it’s more glamorous relative, severity. Priority is however a factor of these two dimensions.

For example of this principle in action, we need look no further than the example at hand: the PNRG generator in OpenBSD. The argument made by the maintainers is that the probability is low enough that regardless of how severe the consequences of the exploit, the chances that it will or can be exploited are low enough that the overall priority is low. This is a questionable assumption with an open source project such as OpenBSD, and with the amount of attention that this particular bug can get.

Developers, and their subspecies crackers, are a somewhat arrogant lot (and I include myself in that bucket, before anyone gets upset). If you tell us that we can’t do something, that usually is just blood in the water. Knowing that this exploit exists, even if we have to work really hard to get to it, well, we’ll try to figure out a way anyway. This adds to the probability, simply because there are so many of us out there. Additionally, the knowledge of this weakness is easily obtained, which also lowers the barrier to entry, again increasing the probability.

There’s always the possibility that someone else will fix the problem and contribute it to the OpenBSD community, since this is open source, but if the maintainers refuse to integrate a contributed fix, that could result in a fracture of the code base, and that isn’t good for anyone.

Time is the only way that we will tell whether the OpenBSD maintainers are correct in their assessment of the probability, and thus the risk involved with this PNRG bug. If proof-of-concept or actual exploits appear for this in the wild, then the maintainers may have little choice except to integrate a fix, or to suffer people moving to other BSD variants that don’t have the same flaw.

Comments