textfiles/virus/comp.vir

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.