[<<Previous Entry]
[^^Up^^]
[Next Entry>>]
[Menu]
[About The Guide]
---------------------------------------------------------------------------
From: bishop@bear.Dartmouth.EDU (Matt Bishop)
Subject: More on the virus
Date: Thu, 3 Nov 88 16:32:25 EST
... This program introduced itself through a bug in sendmail. At these
sites, sendmail was compiled and installed with a debugging option
turned on. As near as I can figure (I don't have access to the sendmail
sources), by giving a specific option to the "debug" command in sendmail
(there are lots of those, controlling what exactly you get information
about) you can cause it to execute a command. As sendmail runs setuid
to root, guess what privileges the command is executed with. Right.
Apparently what the attacker did was this: he or she connected
to sendmail (ie, telnet victim.machine 25), issued the appropriate debug
command, and had a small C program compiled. (We have it. Big deal.)
This program took as an argument a host number, and copied two programs
-- one ending in q.vax.o and the other ending in .sun.o -- and tried to
load and execute them. In those cases where the load and execution
succeeded, the worm did two things (at least): spawn a lot of shells
that did nothing but clog the process table and burn CPU cycles; look in
two places -- the password file and the internet services file -- for
other sites it could connect to (this is hearsay, but I don't doubt it
for a minute.) It used both individual .rhost files (which it found
using the password file), and any other remote hosts it could locate
which it had a chance of connecting to. It may have done more; one of
our machines had a changed superuser password, but because of other
factors we're not sure this worm did it.
This last part is still sketchy; I have the relevant sun.o file
and will take it apart to see just what it was supposed to do. As of
now, it appears there was no serious damage (just wasted CPU cycles and
system administrator time).
Two obvious points:
1. Whoever did this picked only on suns and vaxen. One site with a lot
of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
but the attempt to get the other machines didn't work.
2. This shows the sorry state of software and security in the UNIX world.
People should NEVER put a program with debugging hooks in it, especially
when the hook is (or can be made) to execute an arbitrary command. But
that is how the sendmail which was used was distributed!
One more interesting point: initially, I thought an application
of the "principle of least privilege" would have prevented this
penetration. But the attacker used a world-writeable directory to
squirrel the relevant programs in, so -- in effect -- everything could
have been done by any user on the system! (Except the superuser password
change, of course -- if this worm did in fact do it.)
I think the only way to prevent such an attack would have been
to turn off the deug option on sendmail; then the penetration would
fail. It goes to show that if the computer is not secure (and like you,
I don't believe there ever will be such a beastie), there is simply no
way to prevent a virus (or, in this case, a worm) from getting into that
system.
I know this is somewhat sketchy, flabby, and fuzzy, but it's all
I know so far. I'll keep you posted on developments ...
Matt
.
This page created by ng2html v1.05, the Norton guide to HTML conversion utility.
Written by Dave Pearson