Handbook of Infosec Terms 2.0/Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso/text/virusl/vl04_056.txt

Internet Message Format | 1996-09-04 | 21.2 KB

From:       Kenneth R. van Wyk (The Moderator) <[e-mail]>
Errors-To: [e-mail]
To:       [e-mail]
Path:      cert.sei.cmu.edu!krvw
Subject:   VIRUS-L Digest V4 #56
Reply-To:  [e-mail]
--------
VIRUS-L Digest   Tuesday,  9 Apr 1991    Volume 4 : Issue 56

Today's Topics:

UNIX & Viruses (UNIX)
Partitions without hidden sectors (PC)
Mac virus question (relayed) (Mac)
Am I subject to viruses?
Re: F-PROT 1.13 vs. 1.14 Bug? (PC)
Re: MDC questions
How big is the virus problem ??
Re: F-DRIVER.SYS (v 1.14) problems & questions (PC)
Re: Unix viruses and damaging programs (UNIX)
Need help with Beijing Virus (PC)
My final comments on the six-byte method (PC)

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.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, 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

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

Date:    Wed, 03 Apr 91 13:34:30 -0500
From:    [e-mail] (A. Padgett Peterson)
Subject: UNIX & Viruses (UNIX)

>From:    micor!esleng!esleng.ocunix.on.ca![e-mail] (Dave Gilmour)

Basically, the sheer diversity of UNIX platforms provides the best
defense against malicious software. Mix in the user/kernel and
"rights" requirements and you have the basis for a good protection
scheme.

Mr. Morris's worm was directed at only two platforms: DEC Ultrix and
Sun/OS as I recall and it had to carry separate code modules along for
each.

Viruses are remarkably sucessful on PCs, not because of the operating
system, though DOS certainly does nothing to stop a virus, but because
every machine from the lowliest 8088 to the mightiest 486 runs the
basic 8086 instruction set at startup. Add in the fact that every
function and every entry address defined in the 27 October, 1982 BIOS
specification still exists and you have the key to the spread of
malicious software.

With UNIX on the other hand, not only is a certain amount of integrity
checking built in to the O/S, but malicious software (and many users)
have no idea if the architecture is based on an Intel 80386, a
Motorola 680x0, the CVAX chipset, or some other RISC or CISC
architecture. To the user, the biggest question is usually whether it
is a C or Bourne shell.

When we talk about "portability" in the UNIX world, we are usually
referring to the fact that ASCII is ASCII and that source code that
compiles on an Apollo can also compile on a VAX. That they use wildly
different run-time-libraries is unimportant at the source-code level.

In comparison, writing a virus that can attack both an IBM-PC and a
MacIntosh would be simpler than one that could affect just the
different varieties of Sun microsystems - no I am not picking on Sun,
I just happen to have those manuals on hand.

In addition, UNIX being a "real" multi-user operating system has had
to layer in many integrity checks to protect users from each other.
These same checks make it much more difficult to spread a virus
without notice.

I am not saying that it cannot be done, just that it would be first,
difficult, and second, would have to be targetted to a particular
platform or platforms.

As yet, we have not seen any real threat to the UNIX platforms that
cannot be countered with effective use of the tools built in. The
biggest danger is still an "accident" by someone with root privilege
and a managerial lack of proper training of system administrators.
(off the soapbox, Padgett)

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

Date: Wed, 3 Apr 91 13:34:30 -0500
From: Padgett Peterson <[e-mail]>
Subject: Partitions without hidden sectors (PC)

>From:    [e-mail] (John-David Childs)
>Subject: FDISK; partitions starting at 0,0,2; Stoned virus; (PC)

>When used in conjunction with F-DRIVER.SYS at startup, I've had no trouble
>with removing the virus.  If F-DRIVER.SYS or some other detection utility
>was not loaded at startup (F-DRIVER.SYS halts the PC if a virus is
>detected), then Nick's and Padgett's comments about corrupted FAT's
>etc. would be apropos.

I would still recommend that people having disks formatted without "hidden"
sectors whose machines are at risk, do a thorough backup and re-partition the
disk using a version that does provide this added protection. The STONED is
not the only virus that is liable to corrupt a FAT in this manner.

An easy way to check is with DEBUG: load the logical boot sector of the
fixed disk ( L 100 2 0 1 ) and the number of "hidden sectors" is contained
in a double word at offset 11Ch (just the first byte is enough unless someone
has more than 255 "hidden sectors" & that would surprise me). For an MFM drive,
the value should be 11h or 17 "hidden sectors", I think an RLL drive will
report 1Ah (26) and a large disk might report 3Fh (63), but if 0 or 1, I
would expect that the FAT might be at risk.

One of the difficulties of restoring a fixed disk infected with the MusicBug
is that this "hidden sector" value is lost and must be restored (DOS SYS won't)
before the disk will boot properly.

                        Padgett

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

Date:    Sat, 06 Apr 91 09:11:00 -0500
From:    [e-mail]
Subject: Mac virus question (relayed) (Mac)

Date sent:  6-APR-1991 09:08:52
  a friend of mine has asked a question regarding a mac virus.  I do
not use the mac and know very little about it.  I will relay an answer
if anyone has one. (my friend is on amateur packet radio, and does not
have access to bitnet)
       --------original msg-----------------------
>Date: 05 Apr 91 17:37:52 EST (Fri)
>From: ka2bqe@ka2bqe.#nwvt.vt.usa.na (Brian Riley)
>To: n2ixl@kd2aj.#nny.ny.usa.na
>Subject: mac virus
>
>Daryll, had troubles with a Mac VIRUS over at Smuggs. Could you see if what
>nfo you can find on BitNet on the mac Virus known as "nVIR B" . I have
>removed it from 3 machines so far - it came to us apparently tucked into
>a copy of STUFFIT whihc is kind of PKZIP for Mac's. I am not sure how
>far it has spread on the mountain yet but want to get a handle on its
>potential for trouble .. ie.e is itw orth panicking the place and cleaning
>house or is it sufficiently harmelss that I can quietly take two weeks
>going from machine to machine and clean it out.
>  tnx for any help you can get me.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Darrell G. Leavitt
SUNY Empire State College (ESC)   ESC VAX: DLEAVITT
403 Sibley Hall                   SUNYNET: SESCVA::DLEAVITT
Plattsburgh, New York, 12901      INTERNET: [e-mail]
PHONE    : [phone]         AMATEUR
BitNet   : LEAVITDG@SNYPLAVA      PACKET:  N2IXL @ KD2AJ.NY.USA.NA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Date:    Sat, 06 Apr 91 07:42:41
From:    pcsbbs![e-mail]
Subject: Am I subject to viruses?

I know that this is the kind of question that only a novice would ask.
Well, I am a *rank* novice in Usenet, UUCP, and telecommunications in
general.  Please bear with me.  The question is:

If I connect to a site where I always initiate the call, only exchange
email and receive netnews, am I subject to receiving a virus.  My
modem is never left on and the port is not enabled for a login.

If the answer to the above is yes, how can I protect my system.  Any
help would be greatly appreciated.

Frank Fiamingo

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

Date:    07 Apr 91 13:45:46 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: F-PROT 1.13 vs. 1.14 Bug? (PC)

[e-mail] (Richard W Travsky) writes:
>I have an older version of the Jerusalem virus (2 years or so) I use
>for testing.  F-Prot version 1.13 detects and removes it, version
>1.14a detects it but doesn't remove it, saying it's an unknown
>variant.

You are right, it is a bug in version 1.14 - It will not remove some
of the Jerusalem variants, athough it detects and stops them all.
This has been fixed in 1.15, which will pe distributed in just a few
days.

- -frisk

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

Date:    Mon, 08 Apr 91 15:22:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: MDC questions

  In answer to some of Jim Kirkpatrick's questions:

>-SNEFRU was discussed on this list, but I was dismayed to find it
> had been broken, and that Merkle's response was to increase the
> number of passes.

  Yes, 2-pass Snefru was broken, but I think only in the sense that it
is computationally feasible to find *some* pairs x1, x2 (x1 != x2)
such that Snefru(x1) = Snefru(x2).  I'm not sure in what context this
type of breaking is significant.  It does not imply that for a *given*
x it is feasible to find an x' != x such that Snefru(x') = Snefru(x)
(unless one collects an enormous number of such pairs (x1,x2), which
hardly seems practical).
  (Btw, 3-pass Snefru is also weaker than expected, but apparently not
by enough to make it breakable in the way that 2-pass Snefru was
broken.)

> .......  Does the multi-pass version slow down the whole process
> (or is it still acceptably quick)?

  Increasing the number of passes slows down Snefru considerably.
Here are some relative times that I once obtained:
                   MD4                         7.9
                   Snefru, 2 passes           17.5
                   Snefru, 4 passes           27.7

  Btw, the source code for Snefru which Merkle supplies does *not*
give correct results on a PC (it ignores 0Dh bytes and halts on a 1Ah
byte).  This is because he neglected to perform his reads in binary
mode.

> Questions:  How does one get MD4?  Has anybody broken it yet or
> even proposed a method?

  I have the source code for MD4 and could send it to you.  As far as
its being broken, I'm pretty sure it hasn't (unless someone is keeping
the fact secret).  Maybe that's because Rivest didn't offer a reward,
as Merkle did :-) .  More seriously, the structure of MD4 is quite
different.

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

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

Date:    Mon, 08 Apr 91 14:20:38 +0100
From:    [e-mail]
Subject: How big is the virus problem ??

After reading VIRUS-L for over a year now, I am still getting the
impression that the true magnitude of the problem is unknown. This
would seem to be especially so in the corporate domain, as I suspect
many companies are reluctant to publicise details of their misfortunes
fearing the poor publicity that is often associated with such releases
(ie. Aldus recalling 5000 Freehand packages ...). Sales of anti-viral
software may not be giving a true indication either, as the media
'hype' may be distorting the true scale of the problem.

I am not suggesting that viruses are not a problem (I too have been
hit :-), but I would be very interested in hearing peoples estimates of
the SCALE of the problem, and reading any material that people may
have regarding this. I would be happy to summarise and post to this
board all the feedback that I get.

Thanks very much,

             Alistair.

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

Date:    08 Apr 91 15:32:53 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: F-DRIVER.SYS (v 1.14) problems & questions (PC)

[e-mail] (Nelson Bolyard) writes:
>With F-DRIVER.SYS installed, there is a 24 second delay when I run a
>TSR called PSFX.  NO error message is displayed, and no warning sounds
>are emitted from the speaker during this inexplicable 24 second delay.

This is odd - F-DRIVER normally only adds a fraction of a second to
the loading time of each program.  I would very much appreciate a copy
of the PSFX program, so I can determine what the problem is.

>In truth, I don't know exactly what protection F-DRIVER.SYS supposedly
>gives me, what types of problems it supposedly prevents, nor what I
>should expect to experience (i.e. what F-DRIVER will do) if and when I
>actually encounter a virus.

The main purpose of F-DRIVER is to prevent the execution of any
program virus on the computer.  If you attempt to run an infected
file, it will not be executed, and a message will appear.  Example:

        This program is infected by the Magnitogorsk virus
        Access denied

If this happens, just disinfect the affected file, or replace it with
a non-infected copy.

I try to keep F-DRIVER.SYS fully up do date, and it is able to stop
around 400 virus variants.  However, unlike F-FCHK, it will not
produce an accurate variant identifiation.

F-DRIVER will also attempt to analyze the system on boot-up, in order
to determine if the machine is infected with a boot virus.  If this is
the case, it will display a warning message and hang the computer,
forcing the user to reboot from a (hopefully non-infected) system
floppy.

I am adding an option in version 1.15 to disable the second feature,
as it occasionally caused problems on computers with network Boot
ROMs.

- -frisk

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

Date:    Mon, 08 Apr 91 01:44:00 -0700
From:    [e-mail] (Morgan Schweers)
Subject: Re: Unix viruses and damaging programs (UNIX)

Greetings,
    A few words on "Unix" viruses...  As far as I can tell they are
not very likely.  First off, the 'kernel' is *NOT* comparable to
COMMAND.COM...  The kernel is more comparable to IBMBIO.COM and
IBMDOS.COM.  The '?sh' programs are more comparable to COMMAND.COM.

    If you are to assume that 'root' has been breached, then you are
in trouble already.  If a person breaches 'root', they are much less
likely to install a virus as install a trapdoor (patching login.c) or
such.  The reasons are manifold...  A few reasons would be that 1) the
executable file format is (as far as I know, anyone care to correct
me?) not as available.  2) REAL security (as in, file-level access) is
implemented in Unix.  This means that non-prived person <X> can't
modify (usually) prived program <Y>.  3) Most viruses exist from the
binary level, so far.  This is difficult to 'spread' since many
machines can be running Unix, but not be binary compatible.

    That generally explains why a virus won't spread too far.  Now let
me take the other side...  I've seen (yes, SEEN) a 'worm' under Unix
that can be very unfortunate.  The example in particular that I saw
involved the PATH statement of most people's .login's, and the fact
that many people put '.'  first in their PATH.  Thus, say you 'cd' to
a directory, and do an 'ls', and there is an 'ls' program in their
directory...  Well, you get the idea.  It was substantially more
complicated than that, but that's the basic idea.  *THIS* (and silly
other security precautions, like proper passwording (or shadowing, or
any of the other miscellaneous topics)) is far more important to deal
with than worrying about viruses under Unix.

    Under MS-DOS, it's not possible to close all the security holes
without throwing out the OS and starting anew.  Under Unix, the
features are there and it's just a matter of implementing them.  The
same is true of most multi-user OS's.  If it's made to provide
seperation between users, then it's magnitudes harder to write a
successful virus.

    One final note...  I believe it has been done by one Fred Cohen,
but I never learned the details of his experiment.  However, the
likelyhood of it spreading *OFFSITE* is virtually nil, which means
your likelyhood of getting it is equivelant.

    I'm *NOT* a Unix guru, however.  I'd *VERY MUCH* like people to
correct me on matters of fact.

                                                --  Morgan Schweers

P.S.  It has been pointed out to me that it is possible to spread a BSI over a
    BBS if it's done on purpose.  I apologize.  Anything is possible if it's
    done on purpose.  What I meant to say is getting a BSI off a BBS is far
    less likely than getting a file infector, and that's a pretty small chance
    anyway.  <Sigh>

+------------------
   I don't speak for my company, since my company doesn't do Unix work.  I do,
and I love it, but I don't get paid for it, so there.       --  [e-mail]
- ------------------+

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

Date:    Mon, 08 Apr 91 15:01:29 -0500
From:    [e-mail]
Subject: Need help with Beijing Virus (PC)

Help!
  I have a 286 12MHz IBM clone in my office that has been infected
with the Beijing Virus.  It has disabled my 3 1/2" floppy disk drive
for me and is infecting any diskette I happen to boot with that is not
write-protected.  Our virus guru found that on the 128th boot of my
PC, the message "Bloody!  June 4th 1989" will show up and then every
six times after that.  This virus lives in the boot sector of my hard
disk.
   Needless to say, I'd like to disinfect my hard disk without having
to re-format it.  I'd like to have a "tool" available to use for the
next time this happens.  Is there anyone who can tell me of a piece of
software (and where to find it), or some method of getting rid of
this?  I have something that may work, but I need a SIGN.TXT file to
run it with.  Could I get a copy of this?  Any help is greatly
appreciated!!!!!
   Please send replies to:

        [e-mail]
or
        Amanda Emerson, phone # [phone]

Thanks!

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

Date:    Wed, 03 Apr 91 21:00:54 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: My final comments on the six-byte method (PC)

I know that many readers of comp.virus feel this discussion about the
"six-byte method" in just a waste of time, and I apologize - but I still
want to clarify a few issues.

I don't mean this to be interpreted as a personal attack on Padgett Peterson,
and I respect his work in the virus area in general, but I just happen to
disagree with how he sometimes presents the "six-byte" check.

Padgett Peterson wrote:

    While the "stealth" seen so far will defeat a program integrity
    check, it will NOT defeat a system integrity check (the six bytes).

I replied:
    The six-byte check is no sustitute for a full system integrity
    check.

Padgett Peterson then wrote:
    I did not think I ever said that it was. In fact in my New York
    paper specific mention was made that it did not detect the 512
    (Number of the Beast). It will also not detect the Alabama,
    Icelandic, EDV, or any virus that does not go resident.
    What was said was that it will detect all currently "common" viruses.

I was just replying to your earlier posting - and while I agree that the
currently existing "stealth" viruses should not be able to evade a full
system integrity check, we have at least one "stealth" virus which is
able to evade the "six-byte" check.  And regarding the claim that it will
detect all currently "common" resident viruses, I must disagree - the
Vienna virus and its 30+ variants are quite common, even though they are
not as common as Jerusalem or "Stoned".

Hovever, basically we agree. Checking the memory allocation (the six-byte
check) before and after running a program will in most cases tell you if that
program was infected with a virus.  My point is just that "in most cases" is
not good enough.

Padgett Peterson wrote:

    An effective defense MUST start at the BIOS level, something that
    has nothing to do with the "six bytes". Such a program's major
    difficulty will be to handle every oddball O/S, partitioning scheme,
    and non-compliant application around.

I more-or-less agree - with the latest viruses managing to bypass all
interrupt monitors, and accessing the ROM BIOS functions directly, it is
clear that 100% defence needs to be at least partially implemented in the
BIOS itself.

>I cannot go into details, but I do have a working program which is
>able to do this - more details next month.

    Is this why the "insulting" of the "six bytes" ? I admit to being
    surprised that someone with your well-deserved reputation and many
    contributions would feel it necessary to harp on admitted flaws in
    something that is not a commercial product but merely a technique
    some people find useful.

No, certainly not - I respect your work in the virus area, but I disagree
with you presentation of the techique, like:

    "it will NOT defeat a system integrity check (the six bytes)"
and
    "What was said was that it will detect all currently "common" viruses."

As long as it is just presented as a simple check to detect if some program
has allocated memory in a "standard" way, I have no objections to the
"six-byte" check -  primitive, but sometimes useful.

- -frisk

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

End of VIRUS-L Digest [Volume 4 Issue 56]
*****************************************