Home » Data Protection » Application Security

In Depth

Geekonomics Excerpt: The Perversity of Patching

In this excerpt from his new book Geekonomics, David Rice focuses on the security and economic impact of patching commercial software. It’s not a pretty picture.

By David Rice

January 02, 2008 — CSO —

The problem with testing software is that it is unlike testing automobiles, bridges, or any other physical item. Unlike physical structures like bridges, which can be tested in a straight forward manner for maximum load bearing capacity, each instruction within software must be tested individually. This is a tedious and complex process as prone to error as creating the software itself. For example, if a bridge can support 200 tons, then it can be rightly assumed by the design engineer the bridge can support all weight less than 200 tons. If a bridge can support 300 fully loaded trucks and the bridge is covered in two feet of ice, it is safe to say the bridge can support a person riding a bike on a sunny day. In contrast, software must be tested for each and every potential value. A software engineer cannot extrapolate between test cases as a civil engineer would be able to do for a physical structure. If one series of instructions within a software application works correctly (for the sake of argument, it can “support” 10lbs), this says nothing about the ability of a similar series of instructions to handle 8lbs, 7lbs, or even 9.9lbs. In the software engineer’s world, each test is separate and distinct, unrelated to and independent from all other tests. This means for even a moderately complex application, billions upon billions of tests must be conducted.

At most, software companies spend about 35 percent of their production time debugging and correcting errors in their products. [58] Unfortunately, due to the immense complexity of testing software, many software errors—particularly damaging defects—remain latent and do not become apparent until a much later time; that is, not until the software application has become popular. By then, it is too late.

As a case in point, Microsoft’s Internet Explorer has a long history of vulnerabilities, making it the poster child of “what not to do” from a security perspective when designing and building a web browser. In response to this unsatisfactory performance on the part of Microsoft to improve its web browser’s security, multiple news columnists and individuals within the Information Security community in 2004 encouraged computer users to forgo using Internet Explorer and use a free, much more “secure” alternative for a web browser called Firefox.[59] Outside of a few thousand early adopters, however, Firefox was certainly a promising new web browser but hardly what anyone would call a popular browser at the time. The call-to-arms changed that, however, and thousands upon thousands of people started downloading Firefox. As friends told friends, Firefox steadily became increasingly popular and increasingly more exposed. Within months of the call-to-arms, similar vulnerabilities that critics complained about in Internet Explorer were being discovered uncomfortably often in Firefox.[60] Not only were they being discovered, but the vulnerabilities in Firefox were being actively exploited by hackers, thus placing computer users in the same dangerous position they were in with Internet Explorer. What happened?