High Voltage Shareware/high1.zip/high1/DIR14/VL6_082.ZIP/VL6-082.TXT

Internet Message Format | 1993-05-26 | 63KB

From lehigh.edu!virus-l  Mon May 24 05:32:55 1993 remote from vhc
Received: by vhc.se (1.65/waf)
    via UUCP; Mon, 24 May 93 18:01:40 1
    for mikael
Received: from fidoii.CC.Lehigh.EDU by mail.swip.net (5.65c8-/1.2)
    id AA24830; Mon, 24 May 1993 15:43:53 +0200
Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA10605
  (5.67a/IDA-1.5 for <[e-mail]>); Mon, 24 May 1993 09:32:55 -0400
Date: Mon, 24 May 1993 09:32:55 -0400
Message-Id: <[e-mail]>
Comment: Virus Discussion List
Originator: [e-mail]
Errors-To: [e-mail]
Reply-To: <[e-mail]>
Sender: [e-mail]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: VIRUS-L Moderator <[e-mail]>
To: Multiple recipients of list <[e-mail]>
Subject: VIRUS-L Digest V6 #82

VIRUS-L Digest   Monday, 24 May 1993    Volume 6 : Issue 82

Today's Topics:

Re: Should viral tricks be publicized?
VMag Issues 1 & 2
Re: Scanners getting bigger and slower
Re: Scanners getting bigger and slower
Re: Should viral tricks be publicized?
Re: Human factor in infections
Re: IDES '93 Conference Proceedings
Follow-up on UNIX viruses (UNIX)
FDISK/MBR with OS/2 boot manager. (OS/2)
RE: OS2SCAN 104 reporting (OS/2)
Virus Haifa-Family2(w)G? (PC)
re: FLIP (PC)
High memory virus? (PC)
Re: TREMOR-infected virus-scanner? (PC)
novi says infected mcafee (PC)
Re: Jerusalem can be a PAIN IN THE BUTT (PC)
MS-DOS 6.0 AntiVirus Update (PC)
Re: Can a write protected floppy be infected? (PC)
Re: McAfee's Scan and Compressors (PC)
Re: Can a virus infect NOVELL? (PC)
Re: MtE anti-viruses (PC)
Re: Copyright of Virus Signatures (PC)
Re: Experimental tracing disinfectors (PC)
Re: MSAV and text-files (PC)
Re: DOS 6.0 and Virus Functionality (PC)
Re: Where to get CPAV virus signature updates (PC)
Re: FLIP (PC)
Activity Monitors (CVP)

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.  (The complete set of posting guidelines is available by
FTP on cert.org or upon request.) Please sign submissions with your
real name.  Send contributions to [e-mail].  Information on
accessing anti-virus, documentation, and back-issue archives is
distributed periodically on the list.  A FAQ (Frequently Asked
Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<[e-mail]>.

   Ken van Wyk, [e-mail]

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

Date:    Thu, 20 May 93 08:38:40 -0400
From:    Y. Radai <[e-mail]>
Subject: Re: Should viral tricks be publicized?

   Phil Coull writes concerning the Inbar Raz discussion:
> I get the sense that this thing is getting blown out of proportion,
> (a storm in a tea cup, as we English would say).

Up to here, I tend to agree with you.  In fact, despite the fact that
I found Inbar's defense of himself quite weak and easily attackable, I
had decided not to reply to his last posting on the subject; I have
more important things to do.

  Unfortunately, people keep misinterpreting me.  I am simply amazed
at how many misinterpretations and irrelevant replies there could be
to my postings:

  First, there were those (apparently incl. Inbar himself) who thought
I was accusing him of being a virus writer.  In reality, I never
said or implied that.  My main contention was that judging from his
article, Inbar's primary motive in writing it was to help the virus
writers.

  Btw, on 21 April, I (along with several others) received a message,
part of which I quote here:
>       Ed Beroset (... moderator of Fido 80XXX asm programming echo)
>mentions a Netmail he got from Inbar when Ed was stopping him from
>posting ASM source for DES into the FidoNet echo.  ....
>       Early in his echo interchanges, Inbar admitted to having written
>viruses, but then "clarified" that he of course had never released any
>of them.

Despite the above testimony, I never accused Inbar of being a virus
writer.

  Then there were the many people who wrote to me asking for a copy of
Inbar's article.  Wasn't it obvious from my postings that I'm hardly
the most appropriate person to ask for this?

  Then there was the personal message I received from someone, attemp-
ting to teach me that "there are a damn lot of reasons why you would
want to have 'anti-debugging tricks', aside from viruses" and copy
protection, and ending with the sentence "You should know that."  My
answer is that my postings concerning Inbar were concerned with *HIS
INTENTIONS*, and since *he* didn't mention other reasons for such
tricks, the above is completely irrelevant to what I was getting at.

   Now you write the following:
> As you are probably aware, but have omitted to mention, there is another
> file called antianti.txt by Michael Forrest. One by one, it takes apart
> Inbar's techniques, and literally "shoots them down" as being of no use
> whatsoever for any modern debugger, that is, all but one, which he then
> gives details on defeating.

Concerning your second sentence, my reply is precisely the same as
above.  It's totally irrelevant to my purposes because it has nothing
to do with Inbar's intentions.
  As for your first sentence, I was not at all aware of Forrest's
article, so your implication that I have suppressed something is
completely unjustified.

> If Inbar is guilty of anything, it is maybe of a slightly inflated ego
> (something we are all guilty of, from time to time), which I'm sure was
> slightly more inflated by your "accusations"!

I couldn't care less what that may or may not do to Inbar's ego.  He's
a 17-year-old kid, which in Israel means he will probably soon be
going into military service for a few years.  Presumably, when he gets
out, he'll be more mature, and maybe, instead of being "on both sides"
(his words), he'll apply his talents to being on the side of the "good
guys" alone.  If so, no one will be more pleased than me.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     [e-mail]

  P.S.  I was about to say that I am now dropping the subject com-
pletely, even if I continue to be misinterpreted.  But since Richard
Hartman's posting just came in, I'll comment on it too.  He writes:
> I don't know about that.  A statement like that could be interpreted
> to be directed at teaching people interested anti-virus techniques
> some of the techniques that are currently being used by the virus
> writers so they could be recognized and defeated.

I would say that if that were Inbar's intention, his article would
have looked quite different.  If, instead of merely giving descrip-
tions and sample code for anti-debugging tricks, he had also given
*counter-measures* in order to deal with them, I would be much more
likely to accept your interpretation.  If I remember correctly, Inbar
didn't give even *ONE* counter-measure.

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

Date:    Thu, 20 May 93 12:36:40 -0400
From:    THE GAR <[e-mail]>
Subject: VMag Issues 1 & 2

Has anyone else seen "VMag"?  It appeared in this weeks Chaos Digest,
and is a magazine dedicated to publishing virus writing tips.  The
first issue contains code for making "The Tiny Virus" "Sub-Zero Virus"
"Leprosy-B Virus" and "1992 Virus".  There is also an article on how
to modify viruses so SCAN (McAffee) can't detect them.  (Some is
source code, some disassembles, and some "debug" compilables).

The second issue contains an article on making PKLite or LZExe
checksum strings show that they have not been changed, a BBS number
for virus discussions, an interview with Skism One (AKA Lord SSS) (in
which he praises John McAfee for helping make him famous) .. a debug
compilable of the Whale virus, and code for the ontario virus, the
1260 virus, the skism 808 source code, and Vienna/Violator source
code.

The question: What do we do about this?  I called the FBI complaint
desk [phone], and talked to "Harris".  He says there are no
violations of Federal law, and that people can print whatever they
want.  He said to me, that if you can go to the library and learn how
to make an atomic bomb, that this certainly was legal.  I mentioned to
him that once you know how to make a bomb, you need a whole bunch of
uranium to do anything, but once you had this publication, you HAVE
the bomb.  He suggested I contact an agent in my area, but told me the
attorney general's office would have to decide whether there was a
case, but he didn't think there was.  The editor of Chaos Digest is a
member of the EFF, (the electronic version of the ACLU), so I would
bet that anyone who messes with him would get a lawsuit.

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

Date:    21 May 93 06:18:46 -0000
From:    [e-mail] (Mark Aitchison, rm814,ext6947)
Subject: Re: Scanners getting bigger and slower

[e-mail] (Inbar Raz)
>But tracing the source UNTIL THE ORIGINAL PROGRAM will load the virus
>resident, wouldn't it? Unless you only VIEW, not EXECUTE. But then again, you
>sometimes MUST execute, otherwise relocational jumps won't work.

You wouldn't simply trace, but trace and watch for any naughty activity. I favo
ur
emulating the program in an artificial environment, but I've just about been
convinced that it is safe enough to trace and check (if you do it properly).
It is possible to quite easily spot when a virus is trying to do something
naughty (including stop your tracing), but difficult to stop a determined virus
from knowing it is being traced. That might be the ultimate weakness of the
otherwise excellant method, although stopping tracing too early is another conc
ern.

Mark.

- ---
- -------------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy       Phone : [phone] a.h. 3371-225
University of Canterbury,                 Fax   : [phone]  or  3642-999
Christchurch, New Zealand.                E-mail: [e-mail]
- -------------------------------------------------------------------------------


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

Date:    Fri, 21 May 93 17:05:07 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Scanners getting bigger and slower

Inbar Raz ([e-mail]) writes:

> But tracing the source UNTIL THE ORIGINAL PROGRAM will load the virus
> resident, wouldn't it? Unless you only VIEW, not EXECUTE. But then again, you
> sometimes MUST execute, otherwise relocational jumps won't work.

No. Don't "view" or "step" or "execute". EMULATE instead! Look at what
TbClean (from the TBAV package) does.

Anyway, while we are speaking about fast scanning: there is a program
that implements a fast wildcard scanning algorithm (a variation of
Boyer-Moor plus hashing). This program is called agrep and is
available in source from cs.arizona.edu. From the same place you can
get a PostScript file which contains a detailled explanation of the
algorithm. This particular file is also available from our ftp site as

ftp.informatik.uni-hamburg.de:/pub/virus/texts/viruses/fastsrch.zip

Regards,
Vesselin

P.S. I am currently attending a course of German language, which eats
up most of my time. This explains why I am posting less often here and
why it has become relatively difficult to get an e-mail reply from
me... :-)
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 17:47:52 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Should viral tricks be publicized?

Y. Radai ([e-mail]) writes:

> >That is, the article is not published there by him, it is picked by
> >somebody who uses the handle "Hawkmoon" from some Fido conference.

> I'm well aware of that; I mentioned it explicitly at least twice.
> What are you trying to prove?

To prove? Nothing; I got the impression that you have not payed
attention to the fact that it has not been Inbar who has published the
article in 40-Hex, so I provided the quote to remind everybody else
about it - just in case they have got a wrong impression too.

> >Most [anti]debugging tricks, as for today, are used within viruses, in order

> >avoid dis-assembly of the virus, as it will be exampled later in this file.
> >Another big part of anti debugging tricks is found with software protection
> >programs, what use them in order to make the cracking of the protection
> >harder.

> As I read this, his primary interest is in avoiding disassembly of
> viruses by AV people; copy protection comes only in second place.  But

Well, I am reading it in a different way: "We'll speak here about
anti-debugging techniques; many of them can be found in the viruses".
I agree that Inbar's wording is not the best one; one could get the
impression ("as it will be exampled later") that the article will list
the code of some actual viruses for illustration. For those who have
not read the article - it doesn't.

> even if we ignore the implied ranking, the very fact that he is aware
> that the tricks he has published can be used to defeat AV techniques
> (even if only among other things) says a lot, as far as I'm concerned.

There are many system tricks which could be useful to somebody who
decides to write a virus. Ralf Brown's Interrupt List is a prime
example. In particular, I don't think that the tricks listed in
Inbar's article will be of any problem to any knowledgeable anti-virus
researcher.

>   Let me put it this way: Would *you* think of posting an article of
> the type which he wrote (which includes code) in a public forum?

Yes, why not... Maybe worded in a slightly different way, but I don't
see any technical information that needs to be censored.

> More
> important, would you be proud of being "ON BOTH SIDES", as Inbar
> describes himself??

No; here I agree with you.

> When you say that you're defending Inbar, is that
> really the type of person or position you want to defend?

I still have the impression that his goals are legitimate.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 17:54:16 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Human factor in infections

Fridrik Skulason ([e-mail]) writes:

> > > they happen occasionally - the worst I have seen was somewhere around
> > > 20.000 machines infected in a single company.

> >Would I be mistaken if I assumed that those companies weren't adequately
> >protected, or was it a new variant?

> They *thought* they wre fully protected...unfortunately, they had not updated
> their anti-virus software for two years.

Weren't other factors involved in this case? Like the infection
comming on a vendor's diskette, or and infected software manager
machine and the manager installing a new product to all the other
computers?...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 19:23:55 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: IDES '93 Conference Proceedings

George Guillory ([e-mail]) writes:

> I hate to bring this up but has anyone received the proceedings from
> the 6th International Computer Virus and Security Conference?

At least none of the VTC participants (there were three of us) have
received them yet. I'll second your appeal to the organizers - due to
bad organization, it was almost impossible to attend the speeches, so
I would like at least to read the submitted papers...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Thu, 20 May 93 09:19:23 -0400
From:    "David M. Chess" <[e-mail]>
Subject: Follow-up on UNIX viruses (UNIX)

> From:    [e-mail] (Pete Radatti)

> That depends on what you consider "wild".  My company tracks Unix
> attacks and provides generic information on such.  Last year there
> were at least 2 attacks of which I was directly aware.  So far this
> year, there was one attack of which I received 2ed hand information
> from a reliable source.

Really?!  That's very interesting.  Can you give any more detail (to
the list or directly to me) about the nature of these "attacks"?  What
sorts of viruses were involved?  Were these just traditional direct
attacks that happened to use a custom virus of some sort as a tool, or
were they cases in which a virus spread to systems beyond the one
targetted by the writer?  (And, of course, are you sure there were
really viruses involved, rather than just misuse of words by someone
reporting a normal Unix security incident?)

DC

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

Date:    Fri, 21 May 93 08:48:41 -0400
From:    [e-mail] (Johan Wevers)
Subject: FDISK/MBR with OS/2 boot manager. (OS/2)

Hello,

My first harddrive (physical drive C:) contains 2 bootable partitions,
DOS 5.0 and OS/2 2.0, and the OS/2 boot manager. I don't know on which level
the boot manager takes control, nor do I know or the MBR is different when
using different operating systems. My direct question is: is it safe to
give the command FDISK/MBR on this drive, or would it destroy something?

Greetings,
- --
J.C.A. Wevers                 The only nature of reality is physics.
[e-mail]


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

Date:    Mon, 24 May 93 02:03:43 -0400
From:    A.Jilka <[e-mail]>
Subject: RE: OS2SCAN 104 reporting (OS/2)

Hi all,
due to the demand of > 15 letters I post it to virus-l. Never thought, that so
many OS2er's watch this forum :)

First an important thing: The doc's are now in a real good state.
Second: if I refer to a virus, I mean any kind of code which is run on
a machine without being used by programs brought up intentionally by the
user. I know that virusfighters need to distinguish between the various
kinds of attack, but to me, as a user, it is not so important if a
bootsector, a stealth, a troian-dropper or whatever virus kills my data.
Third: My system IS clean. I do not possess any viruses to test the pro-
gram, I even do not have a possible string of a virus to trigger a scanners
virus-found-message.

OS2VAL: Running OS2VAL without any commandlineoptions brings up some
helpful lines giving "VALIDATE SCAN.EXE" as example. How about something
like printf("%s SCAN.EXE", *argv(0)) I hope it is correct, as I'm not a
C-expert, but *argv(0) should point to the running programs name.
The possibility to use wildcards for checking files would be a nice feature.

OS2SCAN:
A word about performance: running os2scan with saved options
"/date /AD /AF cd-chksum.log" took 4'15" to scan on 2 disks through 3377
files where 353 files matched one of the default-extensions.
Drive C: is a Maxtor 7080A and D: is a SEAGATE 3144. Both IDE, both
HPFS. Though OS2SCAN can be run in the background, more than 4 minutes
is too slow on a 486/33 256k machine with nothing fancy running in other
sessions. I remember running SCAN against F-Prot on a DOS-machine with
more than 2200 files, where SCAN was rather slow too. This is why I don't
use SCAN on a regular basis.

The silly option to modify executables is still there. WHY ??? McAfee is
aware of the problems which might occur for instance with LOTUS 1-2-3.

I am still wondering about extensions *APP,*PRG,*XTP. I have never seen them,
but why don't you include extensions of systemfiles with executable code,
like *ADD, *DMD (both are drivers, and I think they usually contain
executable code.) and especially the inevitable *DLL, which is used in WINOS2
as well as OS2 ? I hope your programmers do have strong reasons, why a virus
can not hide there.(I'm NOT talking about current ones, which track down
interrupts for infectable code.)

Switch /RF: still I do not understand its use. Can't I simply delete the
file containing the validation-data ? Though, it's a nice service :)
The only use I can think of, is to remove validation-data for a group or
a single file, but this is not made clear in the doc's. Anyway: it simply
does not work at all. OS2SCAN tells, that it is sorry for not understanding
/RF :( The helpmessage is wrong, too. It proposes to try "SCAN /help", which
surely will fail, as the program is called OS2SCAN.


>/SAVE - This option stores any listed options for subsequent
>        executions of OS2SCAN.
This behaviour brings a problem for unexperienced users: if the switches
/AF /AG /AV are saved, then the checksums will be replaced with every
subsequent scan... A safe method to hide unknown virusattacks. These
switches need to be excluded from being saved, just like the "/SAVE"-switch
itself. And BTW: why is /AF and /AF incompatible (one from the *INI, the
other from the commandline) but NOT /AF and /CF ??? Either the checksums are
to be created, or the are used for comparison. Create and compare in one step
looks a bit strange to me. The best reaction I received from the program, was
the help-page, or that (I deleted it) it could not find the "c-check.log".
/CF c-check.log was in the *INI, but I wanted to create a new logfile by
using /AF.

The problem with the "/save", "/date" and "/showdate" switches persist. After
saving the options, there is a *ini created. /AF cd-chksum.log creates after
a long time a file with checksums inside. If you then use "/showdate" scan
claims, that the logfile has been damaged ... :( The idea, to save the date
within the *ini seems to be too simple. Another guess was, that the file gets
damaged, if you scan the drive, where OS2SCAN resides and put the checksum-
data. But this is not the case. I scanned drive C: with OS2SCAN and the
checksum-data on drive D:. Same rsult after trying to verify drive C: with
option /CF: Sorry, c-checksum.log has been damaged ... :(
Aryeh, please, would you tell us, why this was not taken care of, though I
notified you about the problem and the possible solution for the storage of
the date 2 releases ago ?
(Then I tested the software on OS2 2.0 GA + SP, now it is the 2.1 beta from
december 92) Another workaround which failed too, was not using /AD but simply
saving OS2SCAN d: /AF test.log /date /save. Immediately after I had scanned the
disk, I asked with a /showdate. I was informed of the saved switches
"d: /AF test.log /date" and that drive d: had not been scanned at all! :(
The same problem is, when you only check drive C: with software and data on
drive D: and the *INI containing nothing but /date. /showdate insists, that
C: has not been scanned at all, /CF c-check.log tells you about a damaged file
and is sorry once more ... me too :(

During my testing I thought, I should replace the saved options with
"/AD /date /CF cd-chksum.log" which will provide some kind of integrity-
checking. As my cd-chksum.log-file was damaged, I deleted it and tried to
rebuild it with the /AF option. Result: "Sorry, I can't find the file ..." :(
The new options must override the saved options. Now you have to change the
default options. However: The change of the switches did not affect the error-
message, that my logfile had been damaged. Therefore: no integritychecking
unless you use /AG or /AV which both modify your files :( The only positive
things I found are, that they find a change of even one single bit.
Another fine story about it is, that using /AV and checking with /CG works
still, and finds the changed bits. You even can remove the validationdata
using /RG for /AV-validation! An improvement might be, to notify the
user of his error.
Just fell over a new obstacle: Sorry, /AF option is incompatible with /AF :(
The message is due to 2 facts: 1) commandlineoptions do not override saved
options in the *ini, 2) /AF can be saved to the *ini. Now I have to change
my default-settings once again ...

Result: Even if the program claims with every errormessage to be sorry about
this, I only can tell: I'm sorry too. I won't pay for this program, as it
simply does not do, what it claims to be capable of. :(
There is still some work to be done. ;)

1) Exclude /AG /AV and /AF from being saved to the *ini
2) Make /date work
3) Make /AF work and drop /AG and /AV
4) Speed up the scanning. Multitasking is no excuse for slow working.
5) /RF is not understood. Its proposed help needs to be updated, too.
   so better drop it completely as it is useless anyhow.
6) Have the commandline-options override the saved options if they collide.

OS2CLEAN:
Generic cleaning with /AF-checksums is fine. I could undo a change of the
*EXE-sign MZ to ZM, and a change of a random-selected bit resulted in an
option to overwrite and delete. The final message in the 1st case needs some
change, as there was no virus which OS2CLEAN claimed to have removed.
Generic cleaning with /AG-checksums appended works too, but a typical OS2-
style *com file (MODE.COM) which starts with an *EXE-sign (MZ), which was
changed to ZM could not savely be undone. One more reason to drop /AG and /AV.
A small difference on /AG and /AV in behaviour: generic cleaning with /AG-
checksums provides you with the option to destroy the changed file, if you
have only /AV-checksums appended to your files, OS2CLEAN just reports a
changed file.

This is all I found about the latest product of McAfee. So I am in good
hope to see at least SOME problems gone in the next view cycles.

Greetings from Austria, Alfred
- --
###############################################################################
Alfred JILKA                # This place intentionally left blank! This place i
Geological Survey, Austria  # ntentionally left blank! This place intentionally
[e-mail]    # left blank! This place intentionally left blank!
[e-mail]     # This place intentionally left blank! This place i
#################Don't cut here, you'll damage the screen !####################

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

Date:    Thu, 20 May 93 07:40:58 -0400
From:    [e-mail]
Subject: Virus Haifa-Family2(w)G? (PC)

We have several PC labs here at Buffalo State College.  Yesterday one
lab with 10 machines was infected with Haifa-Family2(w)G.

This virus was in the Printer.sys file in the DOS subdirectory. I was
able to clean the 10 machines using the latest version of Virex.  Does
anyone know what this virus does?

Paul Reynolds
Instructional Support specialist
Buffalo State College
Buffalo, NY

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

Date:    Thu, 20 May 93 09:29:51 -0400
From:    "David M. Chess" <[e-mail]>
Subject: re: FLIP (PC)

> From:    [e-mail] (Mike Dunn)

> Again, does anyone have any information about FLIP, or how something like
> this could be prevented in the future?

The 2153-byte strain of the FLIP is actually the most common, I think.
It infects COM and EXE files, and the master boot record of the hard disk.
Running an infected program infects the master boot record, and
booting from an infected hard disk loads the virus into memory.
While active, it infects programs that are executed.  It has no
intentionally destructive payload; I've only seen it damage files
very rarely.  It's possible that the attacker did the damage directly,
and then installed the virus as an added bonus.   The intentional
payload of the virus is a routine that turns the display upside-down
(including redefining the character set so all the characters are
upside-down), sometimes on the second day of the month between
10 and 11 a.m., on systems with EGA-compatible displays.

The way to prevent this from happening in the future is to keep
good backups of the system, to use BBS software that doesn't allow
random malicious bozos to do whatever they want to your system (no
criticism of ROBOBOARD here, as I know nothing about it; but a
well-set-up BBS should be immune to this sort of cracking),
and to use anti-virus software to prevent common viruses like this
from infecting you by more indirect means (sounds like you're
already doing that).

- - -- -
David M. Chess                    /      Madonna Iguana
High Integrity Computing Lab      /        Sine Theta
IBM Watson Research

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

Date:    Thu, 20 May 93 13:30:18 -0400
From:    Glenn Smith <[e-mail]>
Subject: High memory virus? (PC)

Are there any viruses that take advantage of high memory?  I've
noticed that some anti-virus programs check the first 1-meg as a
default, while others require you to use options (why not a default on
those?)

I can see where a virus could get loaded high accidently if it's
attached to a program that is loaded high (DEVICEHIGH, LOADHI, various
other methods).  But I haven't heard of any that load themselves there
automaticlly. It seems to me that a modern virus would look for high
memory and load there.

What about viruses that load into XMS, or EMS?  A small
loader/controller could be used to control access to the actual virual
code.  I can't think of any anti-virus program that checks beyond 1
meg.  Only the loader/controller could be detected, but might not be
recognized as a virus related program for quite awhile.

Finally, given that 486s have an internal cache, could a virus be
written that hides in the cache?  The 486 has methods of enabling and
disabling the cache, clearing the contents, and so on. (This would be
a very tough virus to write).

+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Glenn K. Smith                 _             University of Texas  |
|                               | |                 at Austin       |
| [e-mail]   __| ~~!                               |
| Phone: [phone]       \     _}        Computation Center    |
| Fax: [phone]          ~'\_(      MicrocomputerTechnologies |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
                     * Chaos is truly interesting!

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

Date:    Fri, 21 May 93 01:44:35 -0400
From:    [e-mail] (Udo Toedter)
Subject: Re: TREMOR-infected virus-scanner? (PC)

Hello Netters,

Yes, our university was also under attack of the tremor virus.
Pascal Pochol from ([e-mail]) wrote a fine tremor killer and i was
able to clean up our infected computer without any data lost. You should
contact him for the cleaner.

There is a second way to remove the virus. Tremor is a stealth virus, he
fading out his viral code if you want to read a infected executable file.
Now you can use the feature to disinfect the files.

on a infected system try:

copy infected.com infected.vom (infected stands for your infected files)

after copying all your files in this way, reboot from a clean disk. After
rebooting rename the .vom files to .com files. I am not sure, that this
method will clean every infected file, you should try it.

Udo

**************************************************************************
** [e-mail]    | Udo Toedter computer station FSU Jena        **
**                       | (between psychiatric clinic and cemetery)    **
** ----------------------|--------------------------------------------- **
** Everybody gets a second chance .... (Mike and the Mechanics)         **
**************************************************************************

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

Date:    Sat, 22 May 93 06:13:23 -0400
From:    [e-mail] (Bill Lambdin)
Subject: novi says infected mcafee (PC)

>From Michael Bannister to All About novi says infected mcafee on 05-13-93
 Internet>[e-mail]

MB| I just installed Borland's Turbo C++ for Windows.  Went Novi runs it
MB| says the C++ exe file is infected with Plastique.  It can not remove
MB| it.  Howerver Mcafee's scan does not detect the virus.  Not
MB| surprisingly, clean won't remove the virus.  Vsum says that both Novi
MB| and Scan will detect Plastique.

It sounds like NOVI is giving you a false alarm.

Bill

- ---
 * WinQwk 2.0 a#383 * Counterfeit PC-cillin found in Bangkok Thailand

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

Date:    Sat, 22 May 93 11:50:43 -0400
From:    [e-mail] (Joe Norton)
Subject: Re: Jerusalem can be a PAIN IN THE BUTT (PC)

Thermo Nuclear writes:

      >in virus protection the moment McAfee discovered [Jeru]. Has anyone
      >else had run ins with Jerusalem?

  When I was a tech at a huge CompuAdd store 3-4 years ago we had
a server from MSU brought into us for "repair".  It had free
onsite service on it through Memorex/Telex, and though the onsite
techs had worked on it 3-4 times over 2 weeks it still wouldn't
work at all.  First thing I did was scan it.  There were 109
infections of Jeruselem on it!  The next thing I did was call the
service manager of Memorex/Telex and yelled at him.  Told him his
so-called techs had been playing typhoid mary with our customers
for over two weeks, and he had better make sure that they
cleaned up after themselves.
                                  Joe

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

Date:    Sun, 23 May 93 15:56:02 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: MS-DOS 6.0 AntiVirus Update (PC)

Well, an update to the MS-DOS 6.0 Anti-Virus has appeared on the
Central Point Bulletin Board (what the number - 503.531.8100 - on page
277 of the ugrade manual reaches). The update is in the form of two
.EXE files, DOSAV (28k) and WINAV (112k). The signature files are
dated 7 May though they appear to have been posted to the board on 18
May.

I have included (below) the text file that is included with WINAV.
Interestingly, the "new virus" list included in the Windows product is
considerably longer than those in the DOSAV text file.

Another interesting point - the CP bulletin board makes mention of
something called "credits". For instance downloading a text file
incurrs a "cost" of 2 "credits" and there is also an "account edit"
space on the BBS though this just produces a screen saying that it is
not yet implimented. Both the WINAV and DOSAV files have a cost of "0
credits". Coming Attraction ?

                    Warmly,
                        Padgett

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

               CENTRAL POINT ANTI-VIRUS SIGNATURE UPDATE

*Signature Update Information for the MS-DOS 6 Windows Anti-Virus Program*

This update works with MS-DOS 6 Windows Anti-Virus Program V1.0 or later.

To update your version of the MS-DOS 6 Windows Anti-Virus Program, follow
these steps:

1.    From the Central Point BBS, download the self-extracting archive file
      as WINAV.EXE to a temporary directory on your hard drive.

2.    Run WINAV.EXE to extract the update signature file, MWAVSCAN.DLL,
      MSAVIRUS.LST and the Read Me file, WINAV.TXT, which contains the
      signature file and an updated list of virus signatures included in the
      MWAVSCAN.DLL file.

3.    Copy the MWAVSCAN.DLL and MSAVIRUS.LST files to the DOS directory on
      your hard drive, or the directory that contains the MS-DOS 6 Anti-virus
      program files.

4.    Run Windows and load the MS-DOS 6 Windows Anti-Virus Program.

The virus list is updated automatically when you run the program.

There are some virus signatures included in the WINAV.EXE file that have the
same name as viruses already detected by your version of MS-DOS 6 Anti-Virus
Program.  As new variants of viruses are found, we may add the variant
signature to the signature file to increase the virus detection capability.
Since the name of the variant is, in most cases, the same as the original
virus name, it will show up in the virus list only once and will not be
added to the total virus count.

******************************************************************************

Additional Virus Signatures included in MWAVSCAN.DLL dated 05/07/93.

Abraxas, AirCop 1, Alien1, Alien3, Ambula, Anna, Anti Cad 3, Tobacco, Arc v9,
Arc v93, Arc V sand, Arcv-1, Arcv-2, Arcv-3, Arcv-4, Athens, BB, BB 1,
Black Jack 8, Bob 1, Boojum, Bopyr, Brazil, Burger, Burger 404, Burger 4,
Busted, Cancer, Cannabis, Carfield, Centry, Chad, China, Chang MPC, Chessy,
Chaser, Civil Def, Clone_v1, Close, CMOS Killer, Code Zero, Col Mac, Soilent,
Color, Comander Bombe, Correos, Cracker Jack 1, Creeper425, Crumble, Cruncher,
Crusher, Dark Avenger 3, Dbl Vision, Decide 2, Demolishon, Demoralize 1,
Demoralized, DIA 444, DIA 465, DIA 602, DIA 606, DIA 608, DIA 620, Diogenes,
Dismembe, DIR 2-A, Dong 2, Dontello, Drop Boot 2, Dropper 4, Dropper 5,
Dropper 7, Dropper 8, Dropper 9, Dropper 10, Ear, Ear 2, AnPrnt, Eearth Day,
EMF-A, Emmie, Emmie 2, End of, Enemy, Enemy 1, Error-Virus, FCB, FamR,
Family, Falcon, Fichv 3, Fm, Forger 2, Friends, Friends 1, Grunt 4, Geek,
Generic, Generic 1, G Spot, Ghost3, Gingerbread, Gingerbread PT, Gotch 1,
Gotch 2, Gotch 3, Gotch 4, Gotch 5, Got You, Green, Grenda, Grunt 2, H&P,
H-621, H-705, H-1508, Hafen 1, Haifa2, Haifa3, Hanji, Hilton, Hilton PT,
Hitler, Azusa 2, Infected, Inject, Intimit, Intruder, Intruder 1, Irish 3,
Itti, Itti 1, Japan Virus, Jason, JD-448, Jo 1, John, Joshi File, Dropper 10,
Keypress 4, New TURKU, KilRoy, Kinsion, Hate, Kode 4, LCV, Lanert, Li Xibin,
Lanert 2, Lisa, Lisa 2, Little Broth, Little Brother, LockUp, Lvvirus, LZ 1,
Maltese Amoeba, Malaise, Mannequin, Massiah, MCWhale, Merde 3, Merde 4,
Merde 5, Merde 6, Mexican, Ministry, Mimic 1, Mimic 21, Munich, Multi 2,
Multi 2 PT, Mut-Rock, MK, MK 1, MK 20h, MPS 1.2, MPS 3.3, Mummy 2, Murphy 6,
Mv 30, Nazgul, Necro, 1963, Nines2, Nitzan, No_start, Npox, Npox 2, Null 178,
Number 1, Number 2, Nygus v2.0, Ontario 2, OW 27, OW 27-B, OW 28, OW 28 B,
OW 30, OW 37, OW 42, OW 64, PC-Bandit 1, Pearl Harbor, Pixl 11, Pixl 12,
Pixel 850, Plague, PLO Virus, Posscas 5, Possessed 3, Possessed 4, Protecto,
Prime B, Psycho, Radyum, Richards, Rob, Rocko 2, Russan A, Sara2, Scroll,
Shhs, Shield, SickSick, Silence, Shz, Skism 808, Small 38, Soilent,
Spanish Fool, Stahlpla, Stanlh, Stealth, Stoned 2, Stoned 3, Stoned 4,
Stoned 5, Surfer, Susan1, Flagyall, SwanSong, Swiss (Phonix), Sylvia 1,
Terminator 2, Terminator 3, Th 1, Th 2, Th 3, Timid 1, Timor, Tiny F, Tmtmid,
Traveller, TRV-50, Troi, Troi 2, Typo 1, Udi, Ultrasik, UNK, V-BNB 3, V512,
VCL Virus, VDL Trojan, Viniscul, Viol-c, Viper, Vootie, , Totoro, Vx1,
Walker, Warrior X, Whywin, Wild B, WinVir 1.4, Wolverine, Wrz_dood, X-3ad,
Yankee, Yankee 2, YAP, Year 1992, Yukon2, Z-10, ZU 1, 132, 1385, 1792, 1992,
205, 256 virus, 2623, 302, 321, 500, 572, 7th Son, 981, 99.

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

Date:    21 May 93 07:02:22 -0000
From:    [e-mail] (Mark Aitchison, rm814,ext6947)
Subject: Re: Can a write protected floppy be infected? (PC)

[e-mail] (Jimmy Kuo) writes:

>Vesselin, be careful how you answer this question.  "Infected" is an
>adjective.  The answer you provide relates to: "Can I infect a write
>protected floppy?"  However, that's a different question.  The answer
>to the question as stated above is, "Yes."
>
>The proof is, I infect a floppy, write-protect it, hand it to you.  So
>"can a write protected floppy be infected?"  Sure!  You'd be holding one.
>
I missed some of this thread - what you say IS in the FAQ (D7), and it is a
good idea to not trust write-protected diskettes (I know somebody that had a
diagnostic disk that got infected, even though they thought it had been
write-protected all the time). But as the FAQ answer says right at the start,
it generally works well... it is just that some people cannot see how a disk
with a write-protect tab on could ever be infected, especially one straight
out of the box from a hardware supplier, etc.
- ---
- -------------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy       Phone : [phone] a.h. 3371-225
University of Canterbury,                 Fax   : [phone]  or  3642-999
Christchurch, New Zealand.                E-mail: [e-mail]
- -------------------------------------------------------------------------------

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

Date:    Mon, 24 May 93 03:32:09 -0400
From:    [e-mail] (McAfee Associates)
Subject: Re: McAfee's Scan and Compressors (PC)

Hello Fabio,

You write:
>Yesterday I got a DIETed file internally infected with Dark Avenger,
>according F-Prot 2.08a, but Scan V104 didn't find anything.
>
>Aryeh:  Does McAfee plan to scan inside DIETed files?
>        What about other compressors?
[...deleted...]

SCAN currently checks inside PKLITE and LZEXE compressed files for
viruses.  We do plan on adding other "run-time compression" routines,
such as DIET, but it is a fairly low priority for us.

Regards,

Aryeh Goretsky
Technical Support
- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice [phone] | INTERNET: [e-mail]
3350 Scott Blvd, Bldg 14 | FAX   [phone] | IP# 192.187.128.1
Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714

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

Date:    Fri, 21 May 93 17:20:35 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Can a virus infect NOVELL? (PC)

Garry J Scobie Ext 3360 ([e-mail]) writes:

> knock.exe program itself surely :-) However, as for 3.11, I haven't
> seen knock.exe work successfully (though I have tested it out). As for

Correct; I think that I mentioned in my messages that the method (not
just the KNOCK program) works only on 3.10 and below.

> earlier versions of netware, I thought it was due to a bug that X
> thousand attempts at login by supervisor would let you in with a nul
> password. Surely intruder detection enabled to 1 or 2 attempts would
> effectively foil this? However, if you know different I'll certainly
> bear it mind :-)

The login process consists of two steps. The first step is to request
a key from the server. Then the LOGIN program encrypts the user
password with this key and sends a login request to the server with
the result of the encryption. The bug is in the generation of server
keys. Sometimes (actually, quite often) they key has a special
pattern, which results in a block of zeroes, if the password
(regardless what that password is) is encrypted with that key. (I am
omitting the details for obvious reasons.)

The intrusion detection logs only the login requests; not the server
key requests. That is, you can repeatedly request keys from the
server, until you get a faulty one, and then send a login request with
the null password. Since the first login request succeeds, the
intrusion detection does not detect anything.

BTW, Novell has issued security patches that fix this particular bug.
Everybody who is running a version of NetWare below 3.11 is strongly
advised to get and install them.

> > It depends... <grin> On 3.11 one could try the method used by the
> > program HACK to spoof a user who is currently logged in. If this user
> > has supervisor rights... well you get it.

> Indeed I do :-) though I believe Novell's security patches should
> help get around this - or will this depend again? :-)

Yup. I mean, "yup, it depends again"... :-)

The hole exploited by HACK is a major design bug in the NetWare. The
packets sent by the workstations are identified by a 8-bit number. If
this number is not correct, the packets are rejected. In practice,
this means that if you broadcast all the possible 256 variants of the
packet, one of them will pass and the server will think that it is the
user being spoofed, talking from the workstation s/he is logged in.

The patch supplied by Novell makes the server clear the connections
that broadcast packets with "wrong" identifiers. In practice, this
means the following:

1) If somebody tries to spoof you from a workstation, the patched
NetWare will log -you- out, not the attacker. This tends to be a bit
inconvenient and allows denial-of-service attacks, but at least the
attacker is not allowed to impersonate you. (S/he cannot do it if you
are not logged in.)

2) If a packet gets lost in a noisy and overloaded network, the patch
will assume a spoofing attack and will log out a legitimate user. This
is -much- more inconvenient, that's why many people refuse to run the
patch.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 17:34:37 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: MtE anti-viruses (PC)

Michal Weis or INFI ([e-mail]) writes:

> VB> 2) CPAV 1.4 and MSAV     'sometimes'
>  'sometimes' meens when not-encrypted? That is so easy (and does not touch
> MtE-encryptor problem)

No, no, "sometimes" means... er... "sometimes". :-) That is, you run
the program in disinfect mode on a bounch of files infected by
different MtE-based viruses. Some of them it disinfects, for others it
tells you that it's a new virus and simply renames the file. OK, so
you generate lots of replicants of the viruses it seems to be able to
disinfect (e.g., a few hundred) you run it again, and for a few file
(e.g., half a dozen) it tells you that they are infected by a new
virus.

The correct statement is to say that CPAV is able to disinfect -some-
MtE-based viruses MOST OF THE TIME. But, of course, this is not what
they are saying in the marketing ads...

> VB> 3) A German anti-virus product, called AntiVir IV.
>  What is it? I've never heard about it. How it works? (heuresic like
> TbClean or ???)

It's a German-only product. The producer is H+BDEV. The detection rate
is good enough (well, F-Prot is better). The disinfection rate is
excellent - about the same as F-Prot. (They claim to be even better
than it, but I have not done detailled tests.)

How it works? As far as I understand - in the same way as CPAV (well,
both of them used to crash on one and the same particular file
<grin>). The infected file is loaded in a memory segment and traced,
step by step. At each instruction, the INT 1 handler checks whether
the next instruction does not try to modify something outside the
memory segment or to transfer control outside it. The idea is to let
the virus decrypt itself, once this is done, trivial virus
identification techniques can be applied. The saved data from the
beginning of the file is also there, readily decrypted.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 17:57:57 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Copyright of Virus Signatures (PC)

Malte Eppert ([e-mail]) writes:

> Me not, too... but it's ridiculous to grant copyrights to code which is
> designed to propagate by itself :-)

Why not? There are many shareware programs that are free to copy and
distribute, yet they are fully copyrighted... What would be ridiculous
would be to grant a software patent for a virus; i.e. a
self-infringing patent... :-) But software patents are ridiculous
anyway... :-)) (For the humor impared - that was a JOKE! Please, don't
start a flame war pro/con software patents.)

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 18:02:01 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Experimental tracing disinfectors (PC)

Malte Eppert ([e-mail]) writes:

> The program TBCLEAN from the TBAV package is such a heuristic cleaner which,
> in most cases, works great. You can, for example, disinfect the TREMOR virus
> with it, which is common in Germany. F-PROT 2.07 has been partially able to
> detect it, that cleaner killed it right from the start, without any
> information about the file when starting to emulate. I wouldn't call that
> experimental :-).

Hm... Have you tried to clean an EXE file, using entirely the
heuristic disinfector (i.e., without a checksum database)? Did you
compare the "disinfected" file with the original one? In many cases
TbClean does not correctly restore all fields of the EXE header -
because the virus itself does not restore them before transfering
control to the original code. If the original program is
self-checking, this means that it will not work after disinfection.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 18:17:09 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: MSAV and text-files (PC)

Amir Netiv ([e-mail]) writes:

> Its like this: Most DATA files are no threat to you, even if you take them to

> another (non infected) computer, they are (at most cases) simply corrupted.
> However some "DATA" files are not what they seem, for example LOTUS
> spreadsheets are practically a kind of overlay thet LOTUS loads and executes.
> So (as the 100-Years (=4096=Frodo) virus successfully demonstarated) it is
> possible to take an innocent "DATA" file to a clean machine and get infected.
> Generally there are not many viruses that do it, but they exist.

The above is a bit unclear; I'll try to add some clarifications.

The spreadsheets are not overlays for LOTUS, of course. But they
contain keyboard macros (among other things) and those macros are
interpretted by the spreadsheet program. In particular, one of them
(with a special name) is interpreted each time you load the
spreadsheet. This allows the possibility for a spreadsheet-infecting
virus. This has been demonstrated to be possible by Prof. Harold
Highland; there's an article in "Cmputers & Security" about it. No
such virus exists in a non-research environment, but it can be done.

Frodo has nothing to do with the above; the problem with it is that it
has a weird algorithm to determine whether a file has an executable
extension (it just sums the ASCII codes of the characters of the
extension), and due to that it sometimes infects files which are not
executable (.OLD, .MEM, etc.). However, some software systems (e.g.
GEM) can store executable code in files with non-executable extensions
(e.g., .APP). If the algorithm of the virus happens to match files
with such extensions, and if the virus infects on Exec function all,
then those files will be infected. A scanner that checks only COM and
EXE files will fail to detect them, yet they might be still able to
successfully spread the virus if Exec'd.

> But usually it is for the best. MSAV is a bit slow, but if the program will
> try to identify each file and determine its true type (instead of relying on
> the extention) it will distinguish data files from executable ones (as V-CARE

> does) and run much faster on the non executables.

Huh? OK, the EXE files are easy, but how do you made the difference between
a COM file and a data file?

Anyway, it might be a good idea for a scanner to scan only COM/EXE/SYS
files by default and automatically switch to "all files" mode after an
infected file is found.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 18:22:02 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: DOS 6.0 and Virus Functionality (PC)

A. PADGETT PETERSON ([e-mail]) writes:

> In defense of Microsoft (oh my), this mechanism is not really "dirty"
> since the operative code is present in low memory at this point. After
> the copy to high memory, all that is necessary to change is the
> segment.

Well, this is exactly what I call "dirty"... :-) After all, we have
been always tought that the correct way to set an interrupt handler is
to use the appropriate DOS finction call or (oh, my) to turn off the
interrupts, change the segment AND the offset of the vector in the
IVT, and turn the interrupts on again... Anyway, Microsoft has decided
to spare a few bytes with this dirty trick and involuntary has made a
few viruses inoperatable, so it's not such a bad thing after all...
:-)

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 18:35:18 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Where to get CPAV virus signature updates (PC)

C K Boon ([e-mail]) writes:

> Can anyone tell me where can I download Central Point Anti-virus
> latest virus signature files please? Thankx mega lot.

They are available from our anonymous ftp site, with the permission of
Central Point Software. The full reference is

ftp.informatik.uni-hamburg.de:/pub/virus/progs/cpav_upd.zip

The updates for NAV 2.0 and 2.1 are also there.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 21 May 93 18:56:43 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: FLIP (PC)

Mike Dunn ([e-mail]) writes:

> A bbs in Vancouver, Canada running ROBOBOARD, has recently been attacked by
> the FLIP virus.  The entire computer was checked for viruses at 2pm. Between
> 2pm and 2:38pm at hacker broke into the system and inserted the virus, which
> came into effect at 2:38pm.  NOTE:  This was a hacker's work, not an uploaded
> file.  Unfortunatly the FLIP virus virtually destryed most of his hard drive.
> I believed it attacked the FAT, destroying almost all data.  Some files were
> recovered.  Some of the bbs, and one on-line game were rescued.  All
> downloadable files were wiped out.  The virus was cleaned out using MCAFFEE
> CLEAN.  The user log was wiped out, so we do not know who committed this
> hanous crime.

Uh, that's pretty strange, because Flip is not intentionally
destructive. Either the hacker has done the damage, or you have messed
something, or CLEAN is buggy, or it has been a new variant of Flip
(listed in order of decreasing probability).

> Does anyone have any information about FLIP?  Can anyone tell us what it
> does, exactly.  All I have is McAffee's data on it.

The virus is described in the Computer Virus Catalog. See the FAQ for
information about how to get the CVC.

> Taken from the file VIRLIST.TXT, givin out by McAffee

The information is wrong (as usual); see below.

> > Virus                   Disinfector    V V V V V V V V V V      V   Damage
> > --------------------------------------------------------------------------
> > Flip (5) [Flip]            Clean-Up    . x x x x x x . . .    2343  O P D L

Must be:                                   . x x x x x . . . x    2343 O L

That is, it does not infect overlays, but can infect the MBR. The
number of known variants is 6 and their infective lenght varies from
2153 to 2365 (+/- 16 bytes padding).

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.2 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

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

Date:    Sun, 23 May 93 02:03:13 -0400
From:    "Rob Slade" <[e-mail]>
Subject: Activity Monitors (CVP)

PRTAVS9.CVP   930522

                         Activity Monitors

Activity monitoring software is often named "vaccine" by commercial
software houses.  Although the analogy should not be stretched too
far, activity monitors do share some characteristics of medical
vaccines, being memory resident and preventative in nature.  An
activity monitor watches for "suspicious" activity.  It may, for
example, check for any calls to "format" a disk or attempts to alter
or delete a program file while a program other than the operating
system is "in control".  It may be more sophisticated, and check for
any program that performs "direct" activities with hardware, without
using the standard system calls.

Activity monitors represent some of the oldest examples of antiviral
software.  Generally speaking, such programs followed in the
footsteps of the earlier "anti-trojan" software, such as BOMBSQAD
and WORMCHEK in the MS-DOS arena, which used the same "check what
the program tries to do" approach.  This tactic can be startling
effective, particularly given the fact that so much "malware" is
slavishly derivative, and tends to use the same functions over and
over again.

It is, however, very hard to tell the difference between a word
processor updating a file and a virus infecting a file.  Activity
monitoring programs may be more trouble than they are worth by
continually asking for confirmation of valid activities.  The annals
of computer virus research are littered with suggests for "virus
proof" computers and systems which basically all boil down to the
same thing: if you restrict the operations that a computer can
perform, you can eliminate viral programs.  Unfortunately, you also
tend to eliminate most of the usefulness of the computer.

Activity monitors may also be bypassed by viri that do "low level"
programming rather than using the standard operating system "calls",
or those which actually replace the standard system calls with viral
triggers.  In addition, while new viral technologies such as
"stealth" and polymorphism have little effect on activity
monitoring, new concepts in viral spread, such as "companion" or
"spawning" viri require new "checks" to be added to monitors.  (The
"newness" of an idea does not have to be all that radical.  One
previously very popular "vaccine", very effective against early boot
sector infectors such as BRAIN turned out to be completely useless
against Stoned.)

copyright Robert M. Slade, 1993   PRTAVS9.CVP   930522

==============
Vancouver      [e-mail]         | Omne ignotum pro magnifico.
Institute for  [e-mail]      |  - Anything little known
Research into  [e-mail]         |    is assumed to be
User           [e-mail]         |    wonderful.
Security       Canada V7K 2G6           |               - Tacitus

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

End of VIRUS-L Digest [Volume 6 Issue 82]
*****************************************