Up With Good Worms

[InfoSec News <isn () c4i org>]

http://www.eweek.com/article2/0,3959,1037127,00.asp

By Jim Rapoza
April 21, 2003 

It's not science fiction. Giant networks of zombie computers are
poised to unleash massive destruction on the Internet. You've read
about it right here in eWeek (see "Thwarting the zombies" by Dennis
Fisher, from the March 31 issue). There are other causes for concern:  
In this space last week, my colleague Timothy Dyck detailed a litany
of root-level vulnerabilities that came to light in March alone; and
worm activity has increased tenfold this year.

But what bothers me most is a strong sense of déjà vu. Every year bad
things happen for security, calls are made to improve security
infrastructure and patching practices, and for each step forward,
there are two steps back. Threats aren't worse because attackers have
gotten smarter. It's either that system administrators have gotten
lazier or are overworked due to layoffs or both.

In most cases, the big security problems you read about every day are
simply due to crackers taking advantage of old problems in tens of
thousands of unpatched systems for which patches have been available
for months or years.

So what's the solution? I think it's time to use the worms' tactics
against them and build good worms that fix problems.

Two years ago I wrote a column about the Cheese worm, which entered
Linux systems that had a known security hole and then patched the
systems. As I said at the time, I'm not in favor of vigilante-type
good worms like Cheese that come out of nowhere. But I do think
trusted security entities like CERT or SANS could create and use good
worms very effectively.

This tactic has been discussed in the security community before, and
there are some strong arguments against the use of good worms. But in
the face of zombie networks numbering tens of thousands of machines,
which could be disabled in a single night by good worms, I'm willing
to take these criticisms on.

By far, the most common criticism of good worms is that they would be
entering systems uninvited and making changes to the system (that's
hacking!). This is generally known as the "It's my system so stay the
heck off of it" defense.

My response to this is that if you haven't protected your system
against well-known holes that have had fixes in place for months or
years, then you obviously have abdicated responsibility for your
system. Your systems are now a threat to others.

With the deadly SARS virus raging in Asia right now, if I decided to
fly to Hong Kong, kiss everyone in sight, then cough in crowded
theatres in New York, I should fully expect to be hauled off to a
hospital and quarantined. I don't think an "It's my body and I can
spread disease if I want to" defense would work very well.

Another argument is that the good worm could make changes to the
system that could cause problems. This is definitely true. So on one
side, we have an unpatched system that's been taken over by malicious
people who could be using it as part of massive attacks to take down
the Internet. On the other, we have a single, poorly managed system
that is likely already having problems and may have a few more. Which
scenario do you think makes for a better Internet?

Of course, a good worm is still a worm, and another argument says that
worms are inherently uncontrollable, meaning that good worms will
cause traffic problems and spread out of control. This is true of most
worms today, but that's only because no one has designed a legitimate,
well-coded and peer-reviewed good worm. One can easily envision simple
controls such as built-in expirations and bandwidth management that
would limit or eliminate these effects.

The argument in response is that creating a legitimate, well-coded and
peer-reviewed good worm takes a lot of time, much too long given the
speed at which worms spread. My reply: Most worms don't take advantage
of a newly discovered problem. Most are using security holes that have
been known for a long time.

There are some questions that need to be answered. Who would design
and manage these worms? The government, CERT, vendors or some
yet-to-be-formed body? Which problems should be addressed by them?  
What's the notification procedure for systems that have been patched
by a good worm? Does it leave a message for the administrator? None of
these are insurmountable roadblocks.

The best course of action is to manage your systems effectively and
keep them well-patched, hardened and secure against problems. Then you
won't have to worry about worms in your own systems, just in your
neighbors'.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.