Jose states:
"However, remember the following things. Even if you knew instantly what vulnerabilities the worm was exploiting and how to prevent its use of that hole, how would you prepare a worm with the patch payload in time to launch it in a meaningful time period? How would you outpace the worm (in about 6 hours, Blaster had reached it's peak propagation speed; SQLSlammer reached that speed in a matter of a few minutes; Witty hit that point in a matter of minutes, too)?"

As a developer I can tell you that you will end up causing more damage than good. By that I don't mean that the number of computers that you help will be less than the number that you don't but the ones that an unexpected change will hurt are also the ones most likely plugged into our economy. I've worked at big firms with large, complex systems and I can assure you that they have good reason to be cautious about patching their systems. Mainly the issue is, often a system patch will change the way the system behaves and often in very complex systems this sort of change alters one or more assumptions that may be critical to the systems design. I myself have introduced very good code that fixes something on such systems only to see another system down stream fail because I wasn't aware of an interaction.

So, for this reason I am against counter-worms. The intention is good, of course, but I think the reality is that patching needs to be planned and well thought out.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/347/32250#32250