Hacker 2/HACKER2.mdf/virus/virusl2/virusl2.250

Text File | 1995-01-03 | 22KB | 506 lines

VIRUS-L Digest   Friday,  1 Dec 1989    Volume 2 : Issue 250

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 [e-mail] (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: [e-mail].
 - Ken van Wyk

Today's Topics:

Network Virus Scanner (PC)
Re: Eddie ? (PC)
Info on Jerusalem Virus (PC)
Re: Sophisticated Viruses (Mac)
DIR EXEC remedies (VM/CMS)
JUDE Virus (?????) Mac
SCANV50
Relay (Bitnet) interactive virus conference
nVir outbreak (Mac)
Virus Update (PC)
Jerusalem B virus
Jerusalem - D (PC)
Multiple infections (PC)
re: Eagle issues (PC)
DIR EXEC question (VM/CMS)

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

Date:    Tue, 28 Nov 89 08:24:13 -0800
From:    [e-mail]
Subject: Network Virus Scanner (PC)

David Grisham asked about the availability of alternatives to NETSCAN.
Tacoma Software Systems produces a network scanner that's equally as
good if not better than NETSCAN.  In addition, they throw in a
prevention program called VIRSTOP that scans programs before they're
allowed to execute and prevents infected programs from spreading.
It's more expensive than NETSCAN but the combined package is pretty
good.  Their address is:
           Tacoma Software Systems
           7526 John Dower Road, W.
           Tacoma, WA 98467

Tim Grant Curry

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

Date:    28 Nov 89 19:38:08 +0000
From:    [e-mail] (Rob J. Nauta)
Subject: Re: Eddie ? (PC)

[e-mail] (Fridrik Skulason) writes:
>I was wondering about a text string that appears inside the Dark Avenger
>virus:
>                Eddie lives...somewhere in time
>
>Wasn't there a character named Eddie in a horror movie ? If so, did this
>sentence appear there ?

All Iron Maiden fans will recognise this, although I'm not one of
them, I do know that part of their claim to fame is their sleeve
illustrations, which features a creature known as 'Eddie' The various
sleeves see him evolve, die, resurrect, enter the future, and on the
last one in the ice-age.  The quote has something to do with the album
before, 'Somewhere in Time' which was more successful.

Greetings

Rob

PS. Do the Ohio and/or Den ZUk virus do any damage apart from
formatting track 41 ?? I'd like to know, there isn't much info on
those...

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

Date:    28 Nov 89 21:29:24 +0000
From:    [e-mail] (Erik Sherk)
Subject: Info on Jerusalem Virus (PC)

Hi Virus Hunters,

    It has been a while since I worked on debrain and I have been
away from this list for some time, so I am a little out of date. Please
forgive me if this has been talked about recently.

    The University of Maryland has been hit by the Jerusalem
Virus. The McAfee programs SCANRES and VIRSCAN have been invaluable
in helping to detect the infection, but they don't help remove it.

    So what I am asking for is:

    1) Is there a Public Domain program that will remove
the virus from a machine?

    2) I would like a detailed description of this virus, i.e.
Is it a boot virus, where in RAM does it live, what INTs does it
steal...

    Please send any info to my mail address, as I don't have
the time to read this list regularly.

Thanx in advance...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Erik Sherk                    [e-mail]
Network Infrastructure                [phone]
Computer Science Center
University of Maryland

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

Date:    28 Nov 89 21:43:05 +0000
From:    ut-emx![e-mail] (Chris Johnson)
Subject: Re: Sophisticated Viruses (Mac)

[e-mail] writes:
>[e-mail] (Chris Johnson) writes:
>>There would be crashes because it's very common for software that
>>patches traps to have interdependencies between its patches, i.e. one
>>patch depends on data discovered and stored for later use by another
>>patch.  Removing only a portion of such patches will be likely to kill
>>the machine sooner or later.
>> . . .
>>Further, restoring traps to their original values is going to remove
>>all of the patches put in place by the System itself - the patches
>>that keep that machine running inspite of bugs in the ROMs, etc.
>>Also, whole portions of the OS and Toolbox will be removed by
>>restoring traps to their initial values (as taken from the ROM) - this
>>will kill the machine for sure.
>
>So what if I remove system patches? You seem to think that I need to
>call every little routine in ROM to do my dirty stuff. What I need is
>say, ChangedResource, WriteResource and perhaps AddResource. What do
>these traps have to do with OS traps? How many system patches are
>there for these traps?  Do you *really* think that the ROM is truly
>and utterly worthless without the system patches? Do you think they
>wrote routines that didn't work at all and then patched them into
>working? Why would I care if there is some small and obscure bug in
>the ROM that could make my virus crash with prob. .000001%, after all
>that is probably the whole idea with the virus after all!!

The point is that you can't know the interdependencies of traps.
Maybe you can get away with some of what you discuss, but it'll be a
matter of luck more than anything else.  And *no* I don't think that
the ROM is utterly worthless and bug ridden, but most ROMs were
created to operate in the context of much earlier system software and
may not be (without the patches that would normally be in place) ready
to cope with the modern Macintosh.  Beyond that, and perhaps more
significantly, Apple's fixes to the ROMs are often made not to the
routine that has the bug, but to routines invoked *by* that routine
which are likely to be, in and of themselves, unrelated to the actual
bug.  See the ongoing discussion of tail patching in
comp.sys.mac.programmer for a full treatment of this subject.

So I think the probability is actually a bit greater than ".000001%"
that your virus will crash the machine *before* it can replicate
itself.  At which point it's just not a virus anymore.

>I don't claim that the ROM is bug free, but your indirect claim that
>every trap is buggy is pretty heavy. (I got that from the "fact" that
>everything will kill the machine "for sure", in case you wonder).

See above - I certainly didn't mean to claim that everything is buggy.
Also, if I can't be sure something will work, when I program, I look
at it as a guarantee that sooner or later I'm going to crash
somebody's machine.  I still make a good number of mistakes (like most
folks), but I think this kind of paranoia is a good idea and steers me
clear of a lot of other problems.  I like to think that all Mac
programmers will exercise similar care in their approach to
programming issues, but, of course you're right, virus authors may not
bother.

>>Writing well behaved patches is a black art on the best of days -
>>writing the sort of un-patching patches discussed here would make that
>>"black art" look like a carefree romp in the sunlit countryside.  I
>>don't think such patches could be implemented safely, and I don't
>>think anyone clever enough to do so would be wasting his time working
>>on viruses in the first place.
>
>This proves you've missed the point entirely. We're not talking about well
>behaved viruses here. And just because you think no one would write one isn't
>exactly proof that no one will...

I didn't miss any point completely.  The first of my points which you
quote above deals with issue of reliability and practicality - I stand
by that statement.  The second of those points was a psychological
one, it was *not* offered as *proof* of anything, just a statement of
what I believe to be a reasonable opinion.  If you have a different
opinion - that's fine.  I hope you and your opinion are very happy
together.  :-)

>>All in all, I don't think the techniques dealt with in this discussion
>>are significant simply because there are too many reliability and
>>compatibility problems intrinsically linked to them.
>
>I do think they are significant though. The whole point with my post in the
>first place was to make people realize that a virus could bypass the
>protective fences of all anti-viral programs (including Gatekeeper) pretty
>easily (theoretically anyway). What if a virus changed the resource map
>directly without going through the ROM at all? We can't just rely on the
>trivial and obvious protection that Gatekeeper et al. provies.

For the reasons I stated above, I still don't think the techniques
dealt with in this discussion are significant.  This is not to say
that there aren't ways around the various virus protection schemes
currently available - there is not now, nor do I believe that there is
ever likely to be, an infallible anti-virus system for the Macintosh.
Nonetheless, I don't think that these particular techniques will be of
service to anyone in trying to get around anti-virus systems.  Since
the failed attempts to create such a virus could, however, cause a few
victims a lot of damage I thought it was important to comment on the
practicality of these techniques.  Techniques that would safely create
more sophisticated viruses, are techniques that I refuse to comment on
in any public forum.  (In general I also refuse to comment on the
techniques that won't work, but I made a rare exception in this case.)

As an aside, Gatekeeper is more sophisticated than Vaccine, and SAM is
more sophisticated than Gatekeeper (although in ways that aren't yet
important, I'm relieved to say).  Gatekeeper is improving and will
continue to do so - I will not be advertising these improvements
because I do not care to notify would-be virus authors of what
Gatekeeper can and cannot do.  The more they're left guessing, the
better-off the rest of us will be.

Further, Gatekeeper, at least, can only be extended so fast because my
resources (free time, money, etc.) are very limited.  To the extent
that this discussion promotes the creation of newer, more
sophisticated viruses we are all done a dis-service - I can only
extend my tools so fast; if you deprive me of time by accelerating the
development of new viruses, you are *not* promoting the creation of
more sophisticated anti-virus tools, instead you're hindering such
efforts.

If you find the protections offered by Vaccine, Gatekeeper and SAM
trivial, I would encourage you to write a better tool.  I imagine that
a lot of people would be very pleased to see another good tool made
available.

>What we need
>is sophisticated protection schemes, and unless there's no discussion of
>potential viruses we might never come up with these schemes in time.

More to the point, I believe, would be the following statement:
"unless we keep up open discussions of this kind the virus authors may
never come up with the ways to bypass the existing protection
mechanisms."

Sharing of information is great, but offering would-be virus authors
important information isn't.  It'll be a dark victory indeed if we get
the more sophisticated anti-virus tools you desire (quite
appropriately) IN RESPONSE TO the appearance of more sophisticated
viruses made possible by these discussions.

I am sympathetic with the desire for more sophisticated tools
(although I think you underestimate SAM), but I don't believe that
this is the way to make them a reality.  If you'd like to pursue these
issues privately, I'd welcome an email discussion with you.
Seriously.

Best wishes,
- ----Chris (Johnson)
- ----Author of Gatekeeper
- [e-mail]

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

Date:    Tue, 28 Nov 89 09:54:00 -0300
From:    Marty Zimmerman <[e-mail]>
Subject: DIR EXEC remedies (VM/CMS)

What are other VM/CMS installations doing to slow down the spread of
the DIR EXEC?  I seem to remember that the CHRISTMA EXEC prompted
someone to write a program to scan/clean the SPOOL queue, and I was
wondering if anything similar is available for DIR.

On this subject: how far should system administrators go to protect
users from this type of "letter bomb".  It seems a bit heavy-handed to
purge ANY file from the queue with a filetype of EXEC, XEDIT, or MODULE.
Is it best to let the users fend for themselves, or overprotect them?

Marty Zimmerman
<POSTMAST@IDUI1>

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

Date:    Tue, 28 Nov 89 10:55:50 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: JUDE Virus (?????) Mac

I saw a posting on VALERT-L stating that a new virus has been found
called the JUDE virus.  Does anyone have any information beyond what
was reported on VALERT-L?  Has this been CONFIRMED to be a virus?
Thanks much.

Greg

Postal address:   Gregory E. Gilbert
                  Computer Services Division
                  University of South Carolina
                  Columbia, South Carolina   USA   29208
                  [phone]
Acknowledge-To: <C0195@UNIVSCVM>

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

Date:    Tue, 28 Nov 89 11:14:12 -0800
From:    [e-mail]
Subject: SCANV50

ViruScan V50 is now out.  It detects the Holland Girl .COM infector
reported by Fidonet SysOp Jan Terpstra in the Netherlands.  The virus
increases the size of infected programs by 1332 bytes and contains a
message about a girl named Sylvia in Holland.  No damage has yet been
reported from the virus.  Will report back when more is known.
Alan

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

Date:    Tue, 28 Nov 89 21:02:51 -0500
From:    "Doug Sewell" <[e-mail]>
Subject: Relay (Bitnet) interactive virus conference

A few problems with the idea:

1. Access: Quite a number of VIRUS-L/comp.virus readers that might
   wish to participate in an interactive conference are not members
   of the Bitnet/NetNorth/Earn network.  These people could not par-
   ticipate.  I do not know for sure if there are interactive confer-
   encing systems for usenet and internet, but I doubt it... and
   COMPU$ERVE is too expensive.

2. If all the participants were on Bitnet/NetNorth/Earn, the Relay
   network probably wouldn't cooperate - many relay sites have 'quiet
   hours' during the day, and time zone conflicts would have some
   users locked out while other users could participate.  Also, the
   relays I'm familiar with limit a channel to 8-10 participants (but
   I'm not sure if there would even be that many, and I'm not sure
   if the ones with the most to offer are on Bitnet).

It is a nice idea, though.

Doug Sewell ([e-mail]), Tech Support, Computer Center,
Youngstown State University, Youngstown,  OH 44555
>> Love it or hate it, your body is yours for life.

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

Date:    Wed, 29 Nov 89 09:39:44 -0000
From:    <[e-mail]>
Subject: nVir outbreak (Mac)

1. Can I warn people that there has been another outbreak of nVirB
on the Macs at Teesside Polytechnic, Middlesbrough, Cleveland UK.
Please check any disks received from here on or after today.

2. Can I apologise to everyone on VALERT-L who received my complaint
about repeated error messages. It should have gone to VIRUS-L. Sorry
to have put even more unwanted stuff in your mail boxes.

Rgds,

Iain Noble

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

Date:    Wed, 29 Nov 89 08:39:40 -0600
From:    Bill Hobson <[e-mail]>
Subject: Virus Update (PC)

     I have finally had a reoccurance of the virus that wiped out
several hard disks in our architecture department.  It has positively
identified as Jerusalem B as I had suspected.  I am sure that it won't
be the last outbreak - this has been the fourth outbreak on campus in
less than 6 months (sigh).  I have an unconfirmed report of the Stoned
virus that I am investigating.  More later as the search continues!

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

Date:    29 Nov 89 20:30:51 +0000
From:    [e-mail] (Jason Griggs)
Subject: Jerusalem B virus

     The Jerusalem B virus started to sweep over the Electrical
Engineering dept. at University of Florida this afternoon.  I'd
appreciate any information as to how the virus works & how to get rid
of it.  Thanks in advance.

||===========================================================================||
||     // //      //---  ||  Gravity: Not just a good idea, it's the LAW!    ||
||    // //_\\   // __   ||  [e-mail]                           ||
|| \\// //   \\ //__//   ||  [e-mail]              ||

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

Date:    Wed, 29 Nov 89 22:59:20 +0200
From:    "Yuval Tal (972)-8-474592" <[e-mail]>
Subject: Jerusalem - D (PC)

For some reason ViruScan idetifies the sURIV 2 as the Jersualem - D virus.
The sURIV 2 is not a varient of the Jerusalem, it is more likely to be
some kind of 1st of April - EXE virus.

- -Yuval

+--------------------------------------------------------------------------+
| BitNet:   NYYUVL@WEIZMANN        Domain: [e-mail] |
| InterNet: [e-mail]                        |
+-----------------------------------+--------------------------------------+
| Yuval Tal                         | Voice:   [phone]               |
| The Weizmann Institute Of Science | BBS:     [phone] * 20:00-7:00  |
| Rehovot, Israel                   | FidoNet: 2:403/136         (CoSysop) |
+-----------------------------------+--------------------------------------+

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

Date:    Wed, 29 Nov 89 21:48:16 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Multiple infections (PC)

Some of the early variants of the Jerusalem virus are known to infect the
same file over and over, but it was thought that no other virus did that.

It seems, however, that the Cascade virus does this too, under certain
conditions. One of the software companies here in Iceland called me
today, asking for help in removing a virus which had invaded their
network. It was obvious that something unusual was going on -
COMMAND.COM was over 50K instead of the usual 25K or so. Examination
revealed that programs on their Novell network server had been
infected multiple times (up to 20 times) with the same virus (1704-B),
but programs on diskettes and local hard disks had only been infected
once.

I just used a quick and dirty solution - ran my disinfection program
20 times, but I would like to know if anyone else has noticed this
phenomena.

- -frisk

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

Date:    Wed, 29 Nov 89 17:56:00 -0500
From:    IA96000 <[e-mail]>
Subject: re: Eagle issues (PC)

Normally I would agree would you. However, many people hunt for VGA
specific applications on BBS's which I guess is why EAGLE.EXE was
said to be a VGA animation of an eagle in flight.

As far as whether it should be considered a trojan, a virus, both
or neither, since two forms of viruses have been detected in it,
and since it is also a trojan, it might be a good idea to consider
as something, don't you think?

EAGLSCAN does not just identify the viruses inside these encrypted
files. Note I said encrypted files. It also hunts for the specific
code used to determine the processor type and the code used to do
the actual disk writes.

In any event, this is the last you will hear on the subject from me.
SWE is swamped with more requests than they can handle and as far as
I am concerned, it is time to turn to another subject.

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

Date:    Wed, 29 Nov 89 11:59:30 +0000
From:    [e-mail],
Subject: DIR EXEC question (VM/CMS)

My boss has just heard about this and got himself into a flap.  (We run,
among other things, a VM/CMS 'service' (if that word can be applied to
VM/CMS) on a 3090/150S.)

We have not seen a copy of it, and we don't know how BITNET/EARN IBM's
are interconnected.  However it sounds from the description like it
must transfer itself using SENDFILE (or TRANSFER) over something like
RSCS.  Is this indeed the case?  (If so, it is unlikely to travel
freely between UK academic IBM sites as we tend to run UK Bluebook for
file transfers, which requires that you know the password as well as
the username on a remote site in order to send them a file.  If it
travels as mail, then password is not necessary of course, but on the
other hand the mechanics of MAIL are such that a user is more likely
to have looked at it before running it, since it is a bit tricky to
'RECEIVE' mail into a separate executable file.)

Of course if we DID end up with a copy on our machine, it could
redistribute itself freely within the machine.  I'm simply trying to
make a value judgement as to the likelihood of our getting a copy from
outside; and to decide exactly how to phrase our warning to users.  It
also affects our protective reaction.  If it transfers via
SENDFILE/TRANSFER we're not going to get it.  If it transfers via MAIL
or some other protocol, we might get it, but it will not show up in
our SPOOL as DIR EXEC...
 Paul Smee, Univ. of Bristol Comp. Centre, Bristol BS8 1TW (Tel [phone])
 [e-mail]   :-)   (..!uunet!ukc!gdr.bath.ac.uk!exspes if you HAVE to)

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

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