Hacker Chronicles 2/HACKER2.BIN/718.VIRUSL6.090

Text File | 1993-06-02 | 23KB | 499 lines

VIRUS-L Digest   Thursday,  3 Jun 1993    Volume 6 : Issue 90

Today's Topics:

Re: IDES '93 Conference Proceedings
Looking for SCO UNIX virus software (UNIX)
Corrections (CPAV) (PC)
Re: CPAV updates? (PC)
What to do about Quox virus? (PC)
Misidentification by F-Prot 2.08a (PC)
Re: On the merits of VSUM (PC)
Re: Bug With Virstop 2.08a & DOS6 Memmaker? (PC)
Re: The Anti-Viral Software of MS-DOS 6 (PC)
Re: Gotta Monkey on My Back!!! (PC)
New scanner -- Looking for code (PC)
Anyone have something like this? (PC)
Redirection Difficulty (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a gatewayed and 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; anonymous postings will not be accepted.
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 (e.g., comments, suggestions, beer recipes)
should be sent to me at: [e-mail].

All submissions should be sent to: [e-mail].

   Ken van Wyk

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

Date:    Tue, 01 Jun 93 15:04:44 -0400
>From:    [e-mail] (Daniel P. Faigin)
Subject: Re: IDES '93 Conference Proceedings

On 27 May 93 18:06:35 GMT, [e-mail] (Joanne Mannarino) said:
> I wrote a letter of complaint to the organization and also sent copies to
> IEEE and ACM which were supposedly sponsors.

Well, you've now heard from at least one of them. Based on the reports from
conference attendees and the response from the conference organizers to the
reported problems, ACM/SIGSAC has withdrawn its "In Cooperation With"
sponsorship from the Computer Security and Virus Conference.

Daniel Faigin
Chair, ACM/SIGSAC
- --
[W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
[Email]:[e-mail]              [Vmail]:310/336-5454 Box#13149
            "And as they say, the rest is compost"

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

Date:    Tue, 01 Jun 93 09:50:23 -0400
>From:    tijc02![e-mail] (David Marks)
Subject: Looking for SCO UNIX virus software (UNIX)

I am looking for any virus checking software for SCO UNIX, SCO ODT. If you
know of any that runs under that please email me. If I get responses, I will
summarize to the net.

Thanks in advance.

- -----------------------------------------------------------------------------
David J. Marks                       |     UUCP:      ...!uunet!tijc02!djm408
Siemens Industrial Automation, Inc.  | Internet:   [e-mail]
P.O. Drawer 1255                     |    Phone:                 615-461-2074
Johnson City, TN 37605-1255          |
- -----------------------------------------------------------------------------

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

Date:    Tue, 01 Jun 93 10:26:14 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Corrections (CPAV) (PC)

>In the referenced article, [e-mail]
>(Vesselin Bontchev) writes:

>>According to Padgett, the updates can be used to upgrade also the
>>MS-DOS version of MSAV - the scanner that comes with MS-DOS 6.0.

Not quite, the signature update for the DOS portion appears identical
(according to FC). The .DLLs (Windows portion) are the same exact size but
are different - probably just logos/messages but haven't checked further.

>From:    [e-mail] (Vesselin Bontchev)

I wrote:

>> As far as the easy disable in memory as documented widely, a tiny TSR
>> (uses no free RAM) could disable the disabler just as easily.

>Nope. The disabler -is- needed - as Yisrael pointed out, MSAV needs to
>turn VSAFE off before it begins to scan the disk. If you don't allow
>disabling of VSAFE, then you won't be able to run MSAV with VSAFE in
>memory. A quick fix is to make the TSR ask the user whether s/he
>really wants VSAFE to be disabled, but this is, after all, a kludge.

Exactly so though do not know why this should be necessary, all MSAV should
be doing is reading the disk (or will VSAFE decide that MSAV is a virus 8*).
I have quite a few resident programs that do not bother any A-V products
(though I have thought that some should...)

>> Finally, given that the signatures are distributed separately, what is to
>> stop an enterprising person from distributing their own signature update
>> for use with MSAV having a much higher detection rate (for a suitable fee
>> of course) ?

>I am not competent in legal matters, but I think that one must obtain
>a permission from Central Point Software and/or from Microsoft, before
>publishing such an update...

Why ? Though I am equally incompetant legally it would seem that CP might
copyright their signatures (and this is questionable, they would have to
prove originality of the strings), what you have is a program that accepts
input. There are no legal restrictions to that input any more than Microsoft
can limit sales of Wallpaper .BMPs or Lotus can limit 1-2-3 templates. What
we are dealing with is a *format* not a program and insofar as I have been
able to ascertain the courts have taken a consistantly dim view on attempts
to restrict these.

>Besides, the format of the updates is not published.

SBO doesn't work for long.

                Warmly,
                    Padgett

Have the a/c compressor mounted in the Judge and about 1/3 of the stucco
off. Might get to do some programming RSN.

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

Date:    Mon, 31 May 93 19:07:39 -0600
>From:    [e-mail] (Marc Slemko)
Subject: Re: CPAV updates? (PC)

[e-mail] (Vesselin Bontchev) writes:

> According to Padgett, the updates can be used to upgrade also the
> MS-DOS version of MSAV - the scanner that comes with MS-DOS 6.0.

The DOS updates can indeed be used with the DOS version of MSAV.  One
simply has to rename the virsigs.cps file to virsigs.ms.  Other than the
included instruction file (copy file to program directory...) the files
are identical in the MSAV and CPAV DOS updates.  Now... the Windows
version... the DLLs and sig files seem completely different.  Maybe
someone who uses DOS 6 should try renaming and plugging the CPAV Win
update files into MSAV Win...

- --
===========================================================================
        Marc Slemko        | [e-mail]
Edmonton, Alberta, Canada  |
===========================================================================

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

Date:    Tue, 01 Jun 93 19:25:23 +0000
>From:    Eriq Oliver Neale <[e-mail]>
Subject: What to do about Quox virus? (PC)

I just now ran across a diskette infected with the "Quox" virus
(according to F-Prot), yet F-Prot cannot remove it, nor does it
have any information about it. I looked in the backlog of messages
on VIRUS-L and could find no recent mention of it.

I'm curious what its particular effects are, bugs, etc. Any sources
of information to be had?

Please respond via e-mail, even though I'll be watching the group
closely for responses....

- -Q

 Eriq O. Neale                              BITNET : LIPS@UNTVAX
 Lab/Network Manager                      Internet : [e-mail]
 Academic Computing Services                   FAX : [phone]
 University of North Texas                 Ma Bell : [phone]
"If I got paid for what I say, I'd either be very rich or very quiet!"

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

Date:    Tue, 01 Jun 93 22:56:35 -0400
>From:    "System Manager, and VAX Gopher" <[e-mail]>
Subject: Misidentification by F-Prot 2.08a (PC)

Greetings.

Our lab just survived our first viral infection.  Symptoms were that any
executable program residing on the hard-drive would refuse to execute, and
the machine would lock up, following booting.  F-Prot 2.08a identified the
virus as a _Screaming Fist_ variant, while McAfee's Scan program said that
it was a combination of a boot sector virus, [Genp], with the _Stickey_
[ML2] virus infecting the .com and .exe files.

One other characteristic of the virus was that it wasn't terribly bright,
in that one of the .com files that it infected was a DCL .COM file downloaded
from my VAX. (for the vaxophobic, it's an ascii text file, similar to a .bat).

I was able to disinfect the [Genp] with complete success using Clean, and
[ML2] with partial success.  Files that were for protected mode applications
tended to be unrecoverable.  F-prot was unable to do either.

Being as we've relied on periodic scanning with F-Prot here at the
university as the primary means of virus detection, how often does
this happen (misidentification, or identifying two viruses as a
third)?  Secondly, does anybody have any further information on the
viruses that the program detected?  We have a lot of data move through
our computers, and would like to avoid losing any more to this type
of incident.

Thank you for your time.

                        -fred

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

Date:    Wed, 02 Jun 93 00:05:11 -0400
>From:    Al Garcia <[e-mail]>
Subject: Re: On the merits of VSUM (PC)

You recently gave some very constructive criticism of Patricia Hoffman's VSUM.
In contrast, McAfee's VIRLIST.TXT provides succinct descriptions of the general
behavior you can expect from any particular virus on it.  One of these types of
behavior is installing in memory, but that's as much detail as it gives on the
matter (again, it's succinct).  As you know, there are many different ways a
virus can install itelf in memory, which is reflected in VSUM.  Here's her
legend - this is from a rather old version, but I wouldn't be surprised if she
still uses the same classification system:

        R = Resident (in memory)
          (below 640k - segment A000)
              a - in unused portion of allocated memory
                  (does not change free memory, such as virus resident
                  in CLI stack space or unused system memory)
                  Example:   Lehigh
              f - in free (user) memory below TOM
                  (does not prevent overwriting)
                  Example:   Icelandic
              h - in high memory but below TOM
                  (Resides in high system memory, right below TOM.
                  Memory is allocated so it won't be accidently
                  overwritten.)
                  Example:   Flash
              s - in low (system/TSR) memory
                  (reduces free memory, typically uses a normal
                  Int 21/Int 28 TSR)
                  Example:   Jerusalem
              t - above TOM but below 640k (moves Int 12 return)
                  (Reduces total memory size and free memory)
                  Example:   Pakistani Brain
          (above 640k)
              b - in BIOS/Video/Shadow RAM area (segment A000 - FFFF)
              e - in extended/expanded memory (above 1 Meg)

Could you please provide some comments on the accuracy of VSUM in this one
specific area of analysis?  The reason I think this is helpful is that it
gives you an idea of what viruses can install in memory without being detected
by programs such as TBDRIVER/FILE, FLUSHOT, SECURE, etc.  For example, the
first two each have a problem detecting suspicious memory allocation and use,
which might allow viruses such as, according to her example, Flash, to slip
past them.  SECURE, on the other hand, doesn't seem to bother alerting the
user when a program makes a TSR request (maybe it's supposed to, but it didn't
in the time that I tinkered with it), which might allow simple viruses, such
as, again by her classification, Jerusalem, to install without any questions.
But obviously, her analysis is of no help at all if it's wrong.  I don't know.
I don't have the viruses to verify any of this.  I only ran a few tests on the
security programs to see if they'd be triggered under the conditions I would
want them to be, above scenarios included.  Thanks.

- -Phil Garcia

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

Date:    Tue, 01 Jun 93 21:49:46 +0000
>From:    [e-mail] (John-David Childs)
Subject: Re: Bug With Virstop 2.08a & DOS6 Memmaker? (PC)

[e-mail] (Mark Medici) writes:
>[e-mail] (Shaun P. Hughes) writes:
>
>I have had experiences similar to Rich's.  If I allow DOS6's MemMaker
>to try and determine the best way to load VIRSTOP from F-PROT 2.08a,
>the system locks hard requiring cold-boot.  However, if I select the
>custom MemMaker option, tell MemMaker that I want to specify which
>files to try and load high, and exclude VIRSTOP, there is no problem.
>
>Note that VIRSTOP is actually loaded into memory, it's just that I
>don't let MemMaker try to fit it high.  After MemMaker is done, I have
>no trouble loading VIRSTOP into UMB (providing enough space is left
>over for it).
>
>So the problem seems only to be that MemMaker's method of determining
>VIRSTOP's size is not working -- not that VIRSTOP is incompatible with
>DOS6's UMB/EMM386.EXE.

VIRSTOP normally takes up 15K.  VIRSTOP /DISK uses 2K.  Could it be that
VIRSTOP /DISK *initially* needs 15K and then shrinks down to 2K, but MEMMAKER
puts it into the wrong region of upper memory based upon the 2K assumption?
I know of many TSR's that "shrink" once their initialization code is complete.

According to the DOS 6 manual, MEMMAKER does not try to figure out the optimal
ORDER of program loading in config.sys/autoexec.bat (I think QEMM does).
The ordering of programs can be crucial for the very reason mentioned
above (program shrinking).  For instance, if VIRSTOP /DISK is loaded from
autoexec.bat there may not be enough upper memory to complete the task
(you may have 8K of upper memory but you need 15K for the
initialization even though the program only takes up 2K in the end!).  If
VIRSTOP is loaded as one of the first programs from CONFIG.SYS (after
DOS=HIGH,UMB of course) then you'll have plenty of room for VIRSTOP and
(possibly) 12-13K of programs you may not have been able to run otherwise
(15-2=13).  On our DOS6 machine (DEC 386-25,2 meg RAM, 80meg SCSI) MEMMAKER
couldn't  squeeze out any further upper-memory than my "hand-optimization"
(I have 2K left) and VIRSTOP was left as-is (no crash after running memmaker).

I would guess that since no-one has complained about QEMM crashing VIRSTOP,
the fault lies with MEMMAKER (surprise surprise surprise - Gomer Pyle). But
whether MEMMAKER can or can't determine VIRSTOP's size or whether the problem
is because MEMMAKER doesn't re-order the loading of programs is a
different question.  I haven't played with QEMM sufficiently enough to know.

- --
                          John-David Childs
                          Consultant, University of Montana CIS
                          UM Student Health Service HEALTHLINE Gopher Admin
                          [e-mail], [e-mail]

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

Date:    Wed, 02 Jun 93 07:28:27 -0400
>From:    Y. Radai <[e-mail]>
Subject: Re: The Anti-Viral Software of MS-DOS 6 (PC)

  Concerning the messages which F-PROT outputs about finding search
patterns in memory, I had written:
>> I therefore think that the problem lies with F-PROT rather than
>> with MSAV or VSafe in this particular case.

Vesselin replies:
> I beg to disagree. Although I have not observed it myself, I have
> received several reports about interaction with SCAN 104 and ghost
> positives. It seems indeed to depend on where exactly is VSAFE loaded
> in memory. And the cause of the problem is, of course, VSAFE and
> nothing else - because it doesn't bother to encrypt its scan strings.

The experimental facts which I have found are this:  Without VSafe
loaded in memory either currently or since booting, I run first MSAV,
then F-PROT.  F-PROT outputs the message "The Telecom virus search
pattern has been found in memory."  Now how can VSAFE be the problem
when *it isn't even loaded in memory*???

  What is clear is that in this case F-PROT is complaining about what
*MSAV* has left in memory, not about VSAFE.  It is also clear that
F-PROT is giving a false positive.  The only question is: Which scan-
ner is at fault: MSAV or F-PROT?  If instead of running F-PROT (after
MSAV) I run SCAN, FINDVIRU, or UTSCAN, no message is output.  Since
the other three scanners disagree with F-PROT, the most likely answer
is that it is F-PROT which is at fault in this case.
  Admittedly, the situation changes when VSAFE is loaded in extended
memory (in this case F-PROT complains that the Stoned pattern has been
found).  This time it may sound as if VSAFE is guilty.  But here
again, the other three scanners say nothing.  So I tend to think that
it is F-PROT which is at fault in the present case too.

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

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

Date:    Wed, 02 Jun 93 16:32:33 +0000
>From:    [e-mail] (Mark Thompson)
Subject: Re: Gotta Monkey on My Back!!! (PC)

[e-mail] (Christopher Fenton) writes:
>
>    Has anyone dealt with the "Monkey" virus before???? It
>has taken up residence in the boot sector of several of my machine
>and I'm trying to establish an appropriate cure, but I can't find
>any referances to it in the literature.
>
>    Any help would be greatly apreciated.  Pertinent e-mail
>is always welcome.

Tim Martin from the university of Alberta has written a program to
deal specifically with monkey.  It can be found via anonymous FTP at

oak.oakland.edu in the subdirectory
pub/msdos/virus by the name
killmonk.zip

I have used it on several machines, and it works just fine.

Ciao fer now,

Mark.
Mark Thompson          |                          |
Faculty of Management      |    640K ought to be enough for anybody!   |
University of Lethbridge  |            Bill Gates, 1981      |
Lethbridge, Alberta      |                          |
Canada              |                          |
- ----------------------------------------------------------------------

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

Date:    Thu, 03 Jun 93 05:08:12 +0000
>From:    [e-mail] (Todd C. Langan)
Subject: New scanner -- Looking for code (PC)

I am currently in the prossess of writing a virus scan specifically
for the especially built network we are using here at work.  I have
found that my work is much easier if I have the actual uncompiled
virus code to work with.  If _ANYONE_ has _ANY_ virus code it would be
much appreciated if you would send it to me at my email address
([e-mail]) or if anyone would happen to know of any
ftp sites where I could view the code.

Please help me if you can.
Thanks in advance!
Todd Langan

- --
          ______       _____
- ---------/     /      /      /     /
- --------/_____/      /____  /_____/    I ask, "Let us contemplate our

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

Date:    Sun, 23 May 93 15:57:00 +0200
>From:    [e-mail] (Waldemar Cichon)
Subject: Anyone have something like this? (PC)

Hi Malte,

you wrote to Hans as follows:

 >> Is it possible that you can get bad sectors because of a virus ?
 ME> Logically yes (e.g. old DISK-KILLER marks three blocks as bad in the FAT),
 ME> physically NO.

I think, a virus can also physically destroy tracs: he has only reformat some
tracs with its own sector numbering. OK, it's only possible on old MFM/RLL or
ESDI-HD-Drives, and I don't know viruses doing this, but like you can see ...
it's possible.

CU,

\    /       /
 \/\/aldemar \ichon

- --- GoldED 2.41
 * Origin: Mail Storage Hillerse - Die Spielwiese (9:491/6031)

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

Date:    Tue, 01 Jun 93 10:29:05 -0400
>From:    Donald G Peters <[e-mail]>
Subject: Redirection Difficulty (PC)

I'm trying to investigate how programs trap I/O and redirect it. The
specific problem that I have is how does a program tell DOS to change
its interpretation of standard input or output (or the other three
standard handles for that matter). None of my books an DOS function
(documented or undocumented) describe how to do this.

To wit, let's say you want to issue the DOS EXEC system call, and the
program you want to EXEC reads and writes to standard I/O. But suppose
you want to have DOS read or write to a file instead of the console.
Now if you were issuing a command to COMMAND.COM, redirection is easy,
but if you are trying to run a program using the DOS EXEC function,
there seems to be no documented way.

Now please don't suggest EXEC('COMMAND.COM','/C pgm parameters >file')
because no malicious software could get away with that. I don't need
to defend against such a weak attack; I want to defend against smart
attacks. How do they do it? (It is done by 4DOS at least.) All I want
to know is what do you do to have I/O redirected at the system call
level.

There are plenty of DOS internal experts here and I'm sure someone knows
the answer here.

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

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