Bad plumbers and leaking software

Like a filthy carpet can feed unwelcome vermin, so bad practice in software development can support criminal intent. Only rigorous process will stop them feeding on crumbs from the developer's table.

On 2 November 1988 Robert Morris released an internet worm, a small piece of C code that employed the buffer overflow tactic.

It was a simple concept, the equivalent of theft by putting a hose through a letterbox and waiting for the owner's private possessions to float out of the window.

Careful software construction would have prevented the overflow by using the equivalent of a ball-cock but, like a shoddy plumber, the software developer can often decide that the problem is unlikely to happen and ignore the issue.

Perhaps worse, inexperience might lead them to believe that a buffer overflow may not even be due.

The C programming language has long been susceptible to such errors, so failure to test for these faults is inexcusable.

Recently, however, a new threat lurking in the grubby carpet has been exposed. The Witty worm struck flawed software from Internet Security Systems on a Saturday morning.

Just one day after the flaw was publicised, vulnerable systems were quickly out of action before patches could be installed.

In other words, Internet Security Systems told users that its tank was about to overflow, but water flooded the building while it was waiting for the plumber.

It's never easy to get a tradesman at the weekend, so timing was a critical part of the virus writer's grand plan.

Other viruses have taken advantage of coding difficulties. Klez, Swen, Tanatos and Netsky made use of a flaw in Internet Explorer, causing automatic execution of attachments on HTML emails.

The Slammer worm exploited what Microsoft called "an unauthenticated remote compromise" in MS SQL Server 2000, which amounts to another buffer overflow attack.

Combining with a design feature of SQL Server, the worm had machines answering remote 'pings' from unknown sources and engaging in never ending conversations with one another, resulting in international meltdown.

The exploitation of coding flaws suggests badly-designed or poorly-tested software. Software development can be extremely complex, as the solution space is vast and there are thousands of ways to solve a problem.

Possible wormholes can only be filled through methodical design, proper testing and considered choice of development lifecycle.

It might be excusable to release software that falls victim to a new and ingenious attack: the unpredictable nature of faults makes life difficult for software testers, who must creatively imagine possible failure modes according to experience and wit.

But in the case of well-known and likely errors, exploitation only points to bad process.

While not all of us build software for worldwide use, all projects have a primary concern of quality and a duty of care to their users.

In particular, developers must make sure that they employ techniques which minimise the risk of creating holes, and then assure quality by review and thorough testing.

It's possible that the writing's on the wall for current methods of customer protection. Witty hit the day after the error in the code had been discovered and publicised, so it could be argued that the vendor should have kept quiet. But this in itself could be considered negligent, so there is little choice but to publish.

Colleen Shannon and David Moore, at the Cooperative Association for Internet Data Analysis, have this to say: "The fact that all victims were compromised ... the day after a vulnerability in that software was publicised indicates that the security model in which end users apply patches to plug security holes is not viable."

If patches merely alert the virus writer, and litigation is looming for unknowing virus spreaders, then the application of better practice in development before the product is released is something we must forcibly demand from our vendors.

William Knight is a software developer.