💾 Archived View for spam.works › mirrors › textfiles › virus › comp.vir captured on 2023-06-16 at 21:01:44.
-=-=-=-=-=-=-
From cucard!rockyd!cmcl2!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw Fri Apr 20 16:55:42 1990
Path: dasys1!cucard!rockyd!cmcl2!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.virus
Subject: Usenet "virus" {Ed. HOAX - no, that's *not* a UNIX variant...}
Message-ID: <0009.9004231214.AA04329@ubu.cert.sei.cmu.edu>
Date: 20 Apr 90 20:55:42 GMT
Sender: Virus Discussion List <VIRUS-L@IBM1.CC.Lehigh.EDU>
Lines: 152
Approved: krvw@sei.cmu.edu
> I have to believe that the same yahoos who think viruses are fun
> things on single-user OS machines like PCs and Macs would love to
> infect Unix and VMS systems, if they could.
They can.
> I really do believe that these systems are more difficult to
> circumvent, and this has, to some extent, accounted for great disparity
> in the number of successful attacks on these systems as compared to the
> single-user boxes.
I believe you're right, *but* source code has little to do with it.
It's been at least 6 months since I posted this little fable.
The Usenet virus: a case history.
A cautionary tale.
The Usenet virus was detected when a user discovered that
a program he had received from the net seemed to have two
versions of malloc included with the source. One version of
malloc might be odd, but people have never tired of reinventing
the wheel. Two versions were suspicious, particularly since they
lead to a name conflict when the program was linked.
The first, lmalloc.c, seemed to be identical to the
malloc listed in Kernighan and Ritchie. The second, bmalloc.c,
was rather strange, so we concentrated our efforts on it... this
time was later found to have been wasted.
After a little work during spare moments over the course
of a week we decided it was actually a clumsy version of the
buddy system (a fast but space-inefficient method of memory
allocation). It might make a good example of how not to write
readable code in some textbook, but it wasn't anything to get
worried about.
Back to the first. It made use of a routine named
speedhack() that was called before sbrk() the first time the
malloc() was called. There was a file speedhack.c, but it didn't
contain any code at all, just a comment saying that it would be
implemented in a future version. After some further digging,
speedhack was found at the end of main.c. The name was disguised
by some clever #defines, so it never showed up in tags and
couldn't be found just by grepping the source.
This program turned out to be a slow virus. When it was
run, it looked for a file 'lmalloc.c'. If it found it, or it
didn't find Makefile, it returned. From then on malloc ran
normally.
If it didn't find it, it reconstructed it using a series
of other routines with innocuous names tagged on to the end of
other files. This was apparently an attempt to avoid overly
increasing the size of any one of the files in the directory.
Then it went into Makefile or makefile (it looked for
both) and added lmalloc.o onto the end of the first list of '.o'
files it found. It then reconstructed each of the extra routines,
and speedhack itself, using techniques familiar to any reader of
the obfuscated 'C' contest. These were tagged onto the ends of
the '.c' files that corresponded to the '.o' files in this same
list. The program was now primed to reconstruct the virus.
On inspection, we discovered that about 40% of the
sources on our system were infected by the speedhack virus, We
also found it in one set of shell archives that we'd received
but never unpacked or used, which we took as evidence that it had
spread to a number of other systems.
We have no idea how our system was infected. Given the
frequency with which we make modifications and updates, it's
likely that the original speedhacked code is no longer on the
system. We urge you to inspect your programs for this virus in
an attempt to track it to its source. It almost slipped by
us... if the author had actually put a dummy speedhack in
speedhack.c we would have merely taken lmalloc.o out of the
Makefile and defused *this* copy of the virus without being any
the wiser.
There are other failings in this program that we have
thought of. We have decided not to describe them to avoid giving
the author of this program ideas we might regret. Some ways that
programs like this can be defeated include 'crc' checks of source
files and, of course, careful examination of sources received
from insecure sites.
- -----
Now I have to make a confession. This whole document is a hoax intended
to dramatize the problems involved with viruses and Usenet. I suspect that
most of you were clued to this by the Keywords line. While playing with the
idea and writing this article several things occurred to me:
First of all, this virus is a much more complex program than any of the
viruses that have been spotted on personal computers. I think it has to be,
based on the design goals that a REAL UNIX virus must satisfy. I have not
attempted to actually implement it because of this.
It must be small, to avoid detection. It must not cause files to
grow without bound.
It must infect foreign files, otherwise it's not a virus... just a
Trojan Horse (like the bogus ARC and FLAG programs on the PC). Trojan horses
are a dime-a-dozen.
It must infect source files, since this is the primary software
distribution channel for UNIX. A virus stuck on one machine is a boring
one.
It must not break the infected program (other than what it might
care to do deliberately).
It must not be obvious from a simple examination of the source (like,
changing main to Main and having a virus-main call Main).
I believe that given these goals (which are, of course, subject to
debate) a simpler program would be successful in infesting more than a
small fraction of the machines that (say) comp.sources.misc reaches.
There are systems immune to this particular attack, of course. Ones not
running UNIX, so sbrk() doesn't work. Or ones with radically different
versions of malloc(). Ones with no 'c' compiler. They are in the minority,
though.
On the other hand a virus of this type could infest a large proportion
of the net before it was found. The virus I described does not cause any
direct damage, except for using up a relatively small amount of disk
space. A more vicious virus is possible.
Other variations of this virus are obviously possible. For example, it
could be tagged onto any standard 'C' library routine... I chose malloc
merely because source was available and because it's something that people
complain about, so they wouldn't be likely to find an extra copy suspicious.
Another good routine would be perror(), for the same reason. This would have
the additional benefit of making the spread of the infection dependent on
an additional random factor, making it harder to detect the virus.
Do I think something like this is likely? No. Especially not now that
I've written this little piece of science fiction. I'm sure that
eventually someone will try something unlike this, I suspect that their
virus would get caught much sooner than 'speedhack', because I think
that more people look at the source than conventional wisdom would lead
you to believe. But, again, this is just my personal opinion. Debate is
welcomed... that's why I did this in the first place: to inject some
sense into the debate currently raging in comp.sys.amiga.
- --
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>
/ \ 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com>
\_.--._/
v Disclaimer: People have opinions, organisations have policy.