Software Patching: Patch and Pray

Patching-the only way to prevent poorly designed software from breaking everything-no longer works. And there's nothing you can do about it. Except maybe patch less. Or possibly patch more.

August 01, 2003 — CSO — Early one Saturday morning in January, from a computer definitely located somewhere within the seven continents, or possibly on the four oceans, someone sent 376 bytes of code inside a single data packet to a SQL Server. That packet, which would come to be known as the Slammer worm, infected the server by sneaking in through UDP port 1434. From there it generated a set of random IP addresses and scanned them. When it found a vulnerable host, Slammer infected it, and from its new host invented more random addresses that hungrily scanned for more vulnerable hosts.

Slammer was a nasty bugger. In the first minute of its life, it doubled the number of machines it infected every 8.5 seconds. (Just to put that in perspective, back in July 2001, the Code Red virus concerned experts because it doubled its infections every 37 minutes. Slammer peaked in just three minutes, at which point it was scanning 55 million targets per second.)

Then, almost in no time, Slammer started to decelerate, a victim of its own startling efficiency as it bumped into its own scanning traffic. Still, by the 10-minute mark, 90 percent of all vulnerable machines on the planet were infected. But when Slammer subsided, talk focused on how much worse it would have been had Slammer hit on a weekday or, worse, carried a destructive payload.

Talk focused on patching. True, Slammer was the fastest spreading worm in history, but its maniacal binge occurred a full six months after Microsoft had released a patch to prevent it. Those looking to cast blame, and there were many, cried a familiar refrain: If everyone had just patched his system in the first place, Slammer wouldn't have happened.

But that's not true. And therein lies our story.

Slammer was unstoppable. Which points to a bigger issue: Patching no longer works. Partly, it's a volume problem. There are simply too many vulnerabilities requiring too many combinations of patches coming too fast. Picture Lucy and Ethel in the chocolate factoryjust take out the humor.

But perhaps more important and less well understood, it's a process problem. The current manufacturing process for patchesfrom disclosure of a vulnerability to the creation and distribution of the updated codemakes patching untenable. At the same time, the only way to fix insecure post-release software (in other words, all software) is with patches.

This impossible reality has sent patching and the newly minted discipline associated with itpatch managementinto the realm of the absurd. More than a necessary evil, it has become a mandatory fool's errand.