VIRUS-L Digest   Thursday, 26 Oct 1989    Volume 2 : Issue 223

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [email protected] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [email protected].
- Ken van Wyk

Today's Topics:

re: IBM's Virscan Program (PC)
Another suggestion for preventing viral spread (PC)
RE: Apple II virus - LODE RUNNER
INIT 29 vs. locked disk (Mac)
Re: Jerusalem Virus Version B detected (PC)
DataCrime Strikes!! (PC)
Xeno--possible new virus? (AMIGA)
SCANv45 and UNVIRUS (PC)
reposting of FICTITIOUS virus story (UNIX)

---------------------------------------------------------------------------

Date:    25 Oct 89 00:00:00 +0000
From:    "David.M..Chess" <[email protected]>
Subject: re: IBM's Virscan Program (PC)

This is the information I have; I think it's still correct (I'm
sure everyone will tell me if I'm wrong!):

        IBM Personal Computer and PS/2 customers may
        order the virus detection program by calling 1-800-426-7282
        from 8 a.m. to 8 p.m.  Eastern time through December 31,
        1989 and requesting the IBM Virus Scanning Program, part
        number 64F1424.  The $35 fee can be charged to
        VISA, MasterCard, American Express, or the IBM Credit Card.

There were also a bunch of security-related announcements from IBM
yesterday that I haven't finished reading yet; there may have been
something of relevance in there.   I haven't seen any mention of
official updates to the signature files.

This program is very similar to the internal version of VIRSCAN that
you saw while working for IBM.

While I'm here, I'll also mention that it's a good idea to get
anti-virus software direct from the owner whenever possible, and not
trust indirect or pirated versions from questionable sources.
Anti-virus programs are obvious candidates for malicious Trojan-Horse
hacks!

DC

------------------------------

Date:    25 Oct 89 09:59:00 -0400
From:    "Damon Kelley; (RJE)" <[email protected]>
Subject: Another suggestion for preventing viral spread (PC)

   Earlier this week I was reading a book by Peter Norton.  There was
a passage about the importance of .OBJ files created by compilers
(esp.  assembly).  While I was pondering the importance of .OBJ files,
an idea hit me: since this type of file is non-executable and can only
run when linked, wouldn't self-attaching viruses be scrambled when the
"host" file is changed to an .EXE?
   Of course, the following factors would come into play:

   -the linker and the compiler must not be infected;
   -there are no viruses present in RAM or the disk(s) of the user;
   -the user must be willing to buy some compilers and linkers with
    as little economic discomfort as possible;
   -virus writers don't know very much about manipulating .OBJ files
    correctly; and
   -the .OBJ file was not compiled with an attached virus.

   In other words, wouldn't it be safer if all programs came .OBJ
files (or ASCII)?  That would eliminate much of the virus transmission
going on now, I think.

Counterpoints welcome.

Damon Kelly
jnet%"damon@umbc"                      "What?  Do I speak for anyone
[email protected]                       else??  Does Reagan remember
[email protected]                    what he did between 1980-'88??"

------------------------------

Date:    Wed, 25 Oct 89 14:21:37 +0000
From:    [email protected]
Subject: RE: Apple II virus - LODE RUNNER

"Non-destructeur" means: that does not destroy info. (So I would guess that
                 it does not alter info on disks)

Olivier Crepin-Leblond (and YES, I am French...)
Computer Sys & Elec. , Electrical & Electronic Engineering,
King's College London, UK.

------------------------------

Date:    Wed, 25 Oct 89 11:45:21 -0400
From:    Joe McMahon <[email protected]>
Subject: INIT 29 vs. locked disk (Mac)

"Thomas R. Blake" <TBLAKE%[email protected]> writes:
>>(Prior to INIT29,  I had been advising my users that if they go
>>to Kinko's they would be safe if they took only their data diskette.
>>But if a data infection  can spread to their application disks,
>>this would not be good advice.)
>>
>>Anyone got the REAL answer?
>
>Well, I assume they're going to Kinko's to print.  (Yes/No?)  I'd say
>if they write-protect their diskettes they have no need to worry.
>
>Macintosh viruses will not spread to write-protected diskettes.

The problem with INIT 29, though, is that inserting a locked disk into
the drive will get the "This disk needs minor repairs..." dialog. If
they don't unlock it the disk will be rejected. If they do, it will be
infected. Cute, huh?

Best option is to COPY the files to another floppy, take it, use it,
bring it home, and INITIALIZE IT IMMEDIATELY.

 --- Joe M.

------------------------------

Date:    25 Oct 89 20:51:54 +0000
From:    [email protected] (Jim Wright)
Subject: Re: Jerusalem Virus Version B detected (PC)


In article <[email protected]> [email protected]
du writes:
| After running Scan 1.1V45 on my hard drive I detected the Jerusalem Virus
| Version B on one of my files.  The file that I detected the virus on had
| not appeared in earlier runs of Scan.
|
| The infected file is UNVIRUS.EXE.  The archive I got it out of was
| UNVIRUS.ARC.  I downloaded this file from the SIMTEL20 PD archives.  I
| immediately deleted the file.  I have never had a reason to the
| program (and I would think that running the program on itself would
| have adverse affects).

I uploaded unvirus.arc to SIMTEL20, after it was sent directly to me
by the author.  I will assert there is no virus in that file.  Of course,
for the program to be able to deal with the Jerusalem-B virus, it must
first identify it.  Apparently scanv is setting off false alarms based
on the identification code present in unvirus.  Scanv previously had
problems with false alarms with one of the author's own programs.

Unvirus.arc is an old version that was removed from distribution at
the request of the author.  No problems, but a newer version has been
released.  Please get unvir6.arc from any of the IBMPC anti-viral
archives.  Unvir6.arc also replaces the file immune.arc.

Now, as for scanv.  The author said previously that he regularly changes
the methods he uses to identify viruses, thus hopefully discouraging
crackers from releasing minor modifications of existing viruses.  It
seems that this incarnation of scanv is triggered by what it sees in
unvirus.

I tested both scanv45 and scanv42.  45 choked on it, 42 gave no false
alarms.  One more curious point.  Scanv45 insisted that Jerusalem-B
was present in memory!  How to explain this?  I *never* executed
the unvirus program, so even it it did have a virus it couldn't load
itself.  No other file set off any alarms.  Where did it come from?
Well, when I unarchived unvirus.arc or unvir6.arc, the archiving
program used more memory than scanv.  Since MS-DOS doesn't clear
memory after programs execute, there was still an image of unvirus
left where the archiver had been working.  Scanv45 barfed on this!
To verify this, I unarchived unvir6.arc, then ran DBASE III+, then
ran scanv45.  This time no virus found in memory.

So in summary, replace unvirus.arc with the current release unvir6.arc.
Apparently scanv45 sets off a false alarm with unvirus (either version).

Neither author should be faulted for this.  But everyone should be
made aware of it.  And don't put blind faith in any one program!!

- --
Jim Wright
[email protected]        (ignore the Reply-To: line)


------------------------------

Date:    Wed, 25 Oct 89 13:51:33 -0500
From:    GX6692%[email protected] (Vince Laurent - work id)
Subject: DataCrime Strikes!! (PC)

I just got back to work today and was notified that ALL our hard drives
at work had to be reformatted since they had the virus on them. We used
IBM's release of VIRUSCAN and the tests were positive - we were hit. I
don't know the extent of the damage on campus yet but other departments
are worried. Is there a 'cure'? Please contact me directly ASAP! Thanks!

                       ---------------------------------------------
                       | Vincent J. Laurent                        |
                       | Computing Information Center &            |
                       |             Computer Learning Center 1    |
                       | Southern Illinois University - Carbondale |
                       | GX6692@SIUCVMB                            |
                       ---------------------------------------------

------------------------------

Date:    25 Oct 89 21:11:00 +0700
From:    "Okay S J" <[email protected]>
Subject: Xeno--possible new virus?(AMIGA)

I received this from Amiga-relay this morning....From all reports, it
appears that Xeno, if it is a virus, is the 1st non-boot infector virus
in the Amiga community. All the others I've seen so far live in the boot
sector and most Amiga anti-virals seem to only worry about the boot sector
and in RAM at the time.
I'll cross-post anything I hear from either side to their respective
lists.

- ---Steve
- ----------
Stephen Okay    Technical Aide, The MITRE Corporation
x6737        [email protected]/[email protected]

*************************CUT HERE CUT HERE*********************************

Date: 24 Oct 89 11:21:03 GMT
From:    MTR780::WINS%"<[email protected]>" 24-OCT-1989 13:36:26.00
Subj:    Xeno - Another bad virus?
From: Anssi Ahonen <[email protected]>
Newsgroups: comp.sys.amiga
Subject: Xeno - Another bad virus?

 Does anyone have information about virus called 'xeno'? This little
beast is living on my hard disk (30 meg Supra, A500) and after many
unsuccesful tries I still haven't find it. It first showed up a few
days ago when I opened the shell and tried to get directory with
'ls'-command.  The shell just gave me 'unknown command ls', and after
that I noticed that also 'CD'-command didn't work. Strangely, the
programs were still in c-dir, just as usual. I loaded my favourite
debugger and examined the broken cli-commands. Both programs were
modified so that they only used DOS.Write to print out 'unknown
command'. The weirdest thing was yet to come! I found a strange file
named '!' in devs-directory. This file was an IFF-picture, black
border, white topaz font text : "You will never catch me, the
allmighty Xeno"

So, this is probably the first virus to write iff-files on your hard disk?

I have now examined most of the programs on my hard disk with debugger,
searching for 'virus-signs', extra code hunks, xor-loops etc, but no luck.

The only facts I know are: Xeno is not a bootblock virus.
                          It doesn't change reset-vectors.
                          I am pretty sure it is some kind of link virus
                          (like IRQ), but much harder to beat.
*********************END FORWARDED MESSAGE***********************************

------------------------------

Date:    Wed, 25 Oct 89 18:23:50 -0400
From:    Tom Young <XMU%[email protected]>
Subject: SCANv45 and UNVIRUS (PC)

RE: Posting by Sean Haynes of Northeastern in vol. 2, issue 222.
  I, too, have a report that SCANv45 is generating a positive for
Jerusalem-B when checking UNVIRUS.EXE.  I don't have v45 yet, so cannot
confirm.  But the copy of UNVIRUS that I've distributed here came from
the hotel.cis.ksu.edu server, not SIMTEL20.  And I have successfully
used UNVIRUS to remove Jerusalem-B infections.  My copy of UNVIRUS does
not set off SCANv42.  I suspect that the fault lies with the newer
version of John McAfee's program.  Someone should confirm this before
people start doubting the integrity of the virus archive sites.
  Thanks.
                            Tom Young, Cornell Information Technologies

[Ed. See Jim Wright's message (in this digest) about SCANv45 producing
false alarms.]

------------------------------

Date:    Tue, 24 Oct 89 20:24:16 -0500
From:    Peter da Silva <peter%[email protected]>
Subject: reposting of FICTITIOUS virus story (UNIX)

This is the "UNIX VIRUS" article I referred to in a previous digest. It
was posted in this form, complete with postscript.

No more than a week later the Internet Worm was loose. I was originally
amused by the irony, but as it became clear that the IW was relatively
uninfective (only infected Sun-3s and VAXen) I felt more secure about my
final paragraph. I still do.

The debate "raging in comp.sys.amiga" at the time was about whether UNIX
was as susceptible to viruses as PCs were. :->

- -----------8<----8<--------------------------------------------------`-_-'--

           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 unsuccessful 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, *NIX support guy @ Ferranti International Controls Corporation.
Biz: [email protected], +1 713 274 5180. Fun: [email protected]. `-_-'
"That particular mistake will not be repeated.  There are plenty of        'U`
mistakes left that have not yet been used." -- Andy Tanenbaum ([email protected])

-----------------------------

End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253

You are viewing proxied material from infinitelyremote.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.