Play and Learn 2/19941.ZIP/19941/PUBE/VIR04022.TXT

Text File | 1994-02-05 | 23.3 KB | 554 lines

         VIRUS-L Digest   Wednesday,  6 Feb 1991    Volume 4 : Issue 22
 ******************************************************************************


Today's Topics:

Re: Preventing boot infectors (PC)
Re: Text in MLTI Virus (PC)
Stoned in Three Hills (PC)
SIGN.TXT Update available on BEACH (PC)
FPROT114 & SORT conflicting (PC)
Hard Disks (PC)
Re: Word Perfect and change checkers (PC?)
Low-Level Protection (PC)
Virex 3.0 INIT problem (Mac)
WP and change checkers, it goes on (PC)
Compressors
Re: Hardware damage?
Easy way to write protect 3.5" disks

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:    Thu, 31 Jan 91 12:13:00 +0100
From:    "Nick FitzGerald" <[e-mail]>
Subject: Re: Preventing boot infectors (PC)

In V4 #17 (28 Jan 91) [e-mail] (Gatliff, William A.) wrote:

>Pardon my input into something I know very little about, but I
>have a question/comment:
>I have observed that, according to a lot of the posts in this
>newsgroup, many of these viri infect the boot sector of a disk.
>
>To help combat this, what would be the possibility of 'delibrately'
>infecting ones boot-sector with a piece of code that would display
>some kind of 'ok' message if it hadn't been tampered with?
>
>For example, as the computer goes to boot, it loads the boot sector
>and prints something like 'All is ok as of ...<maybe insert a date
>here.> as instructed by the program that lies there (the one I *put*
>there.)  Ok.  Now, if the user doesn't see that message when he boots,
>he can suspect that all is not ok.  Maybe this piece of code would run
>some kind of check on itself to be sure it hadn't been relocated or
>something...

If you did this and the "All is OK" didn't come up you could well
suspect a boot sector infection, but I'm afraid this isn't a good
diagnostic.  Many boot sector infectors make a copy of the original
boot sector and store it somewhere "safe" on the infected disk/ette.
What happens at boot-up is that the virus code is loaded *as if* it
were a "proper" boot sector (the BIOS program that does this is very
"dumb" as regards the contents of the boot sector).  The viral code is
then executed as the boot sector code would be and it does whatever
(with STONED, for example, it installs itself at the top of memory and
reduces the ammount of available memory, looks for an uninfected hard
disk to infect and so on).  The virus then loads the original boot
sector from its hiding place and passes control to the boot sector
code.  The machine then continues to boot "as normal".

If a virus such as STONED infected a machine with a cherry "All is OK"
message in the boot sector, you would continue to see this now
terribly misleading message after the STONED code loaded and passed
control to the original boot sector.

If the "All is OK" boot sector did a check of the actual (physical)
boot sector then it wouldn't give an erroneous message if the disk was
infected with STONED or similar boot sector infectors, but it would
still give a misleading report if a stealth boot sector infector
struck, as the virus would intercept the attempt to read the boot
sector and return the contents of the original from its hiding place.
(This seems to be a lot of extra code to jam into a single sector, so
to do this an "All is OK" boot program may have to deal with loading
in extra sectors of code, etc remembering that you don't yet have
access to the DOS file handling calls to readily locate that code.)

- ---------------------------------------------------------------------------
 Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
 Internet: [e-mail]        Phone: [phone]

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

Date:    31 Jan 91 15:15:47 +0000
From:    [e-mail] (Lloyd E Vancil)
Subject: Re: Text in MLTI Virus (PC)

[e-mail] writes:
>Regarding the discussion about "Eddie," I have always associated the
>phrase,
>  "Eddie die somewhere in time"
>along with the action of randomly picking a location to kill with the
>book Slaughterhouse 5 by Kurt Vonnegut Jr, where the hero has become
>unstuck in time.
>
>Am I alone?

I am new to this group but I would associate Eddie and "Crazy Eddie"
with "The Mote in God's Eye" -I forget the author's name- But to go
"Crazy Eddie" was to discard the accepted meme's and conventions of
society and do something out of racial character.  As I think more
about it, I think the Author was Niven/Pournell.  Seems to me those
who write viri are "Crazy Eddie"

- --
      *      suned1![e-mail] sun!suntzu!suned1!lev
          .                [e-mail]        +      .
    +          *       S.T.A.R.S.! The revolution has begun!   *
      My employer has no opinions.  These are mine!

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

Date:    Mon, 04 Feb 91 11:10:31 -0800
From:    [e-mail] (Rob Slade)
Subject: Stoned in Three Hills (PC)

The following messages are crossposted from the SUZY network, in the
Religion/INspiration section.  The original infection was at a Bible
school in Three Hills, Alberta, which managed to get the "Stoned" virus
onto a network of computers in teh Library.  The response of the school
was to ship all the computers to Calgary to be reformatted.  All data
entered on the system to that point had to be re-entered manually ...

> GrapeVine > Computers in Ministry > Slade, Greg ======

  Subject: Nobody is safe

  The January 8th issue of ChristianWeek carries a news item from
  Wesern Report that Prairie Bible Institute in Three Hills,
  Alberta, was hit by the "Stoned" virus this winter.  I find this
  story doubly frustrating: not only is it added evidence that
  churches and other Christian organizations need to pay more
  attention to issues of computer security (see INtegrity for the
  tools you need), it is a glaring example of the failure of
  Christians to communicate with one another.  I have been trying
  for 3 years now to give Christian computer users they need to do
  their tasks effectively through various channels (Christian Info,
  CAMsoc, Church Bytes, CITC_NET, and Suzy), including warnings
  about computer viri, yet despite my best efforts, an institution
  which I visited *last Spring* gets hit by a virus, and spends way
  too much time and money dealing with it.  When are we
  Christians going to learn to network?


Date: 28 Jan 91 20:55
From: Lyle Smith on 7501/0  Unlisted node
  To: Greg Slade on 7501/132  Unlisted node

Hi Greg:
        I regret to inform you that I will be pulling the plug on
Prairie BBS as of Jan.31/91.  I hope its not too late to cancel my
listing in the article you were preparing.  One of the key reasons for
going down is lack of usership.  Although Three Hills is a small town by
city standards it probably has as high a computer user ratio per capita
as anywhere due to the college. A significant number of those do not
have modems but a good number do have modems.  However not enough were
interested in the messaging capabilities of the computer medium.  On an
average week I saw maybe 4 or 5 users.  A busy week might bring 8 or 10.
Yes, that's per week!!!  No messages were ever sent out (other than my
own) and the main interest among those who did use the BBS clearly was
downloading files.  When my video card fried itself recently, which I
believe was due to the wear and tear of continuous running (heat
mainly), I decided it wasn't worth the expense.

        I noted with some chuckles your note in the missions echo re:
the stone virus at Prairie.  I have modemed for 5 years and never caught
a virus until I gave a disk to the computer department to format and on
which to store some student scan tron scores.  They passed the virus
along to me on that disk but I didn't use it right away and so when I
heard there was a possible virus I ran McAfee's SCAN checker on the disk
and it picked it up instantly and told me exactly what variety virus it
was.  When I suggested, after the incident, that they need a security
system and in addition to virus checkers they should limit user access
to some terminals I was told by one individual: "We can't stop trusting
people." To their credit they now have purchased some virus checking
programmes but I am not so sure they have implemented any further
precautions re: users to their terminals. All of this is part and parcel
of the frustration I have struggled with of getting people interested in
the computer/modem communication medium.  If people took the time to
avail themselves of what is so easily available to us we likely would
not, as you pointed out, have borne the expense of this incident.  The
sad part, from my perspective, is that I cannot say for sure that the
lesson has yet been learned.
=================


Vancouver          [e-mail]           _n_
Insitute for       [e-mail]          H
Research into      (SUZY) INtegrity                 /
User               Canada V7K 2G6                O=C\
Security                            Radical Dude   | O- /\_
                                             /-----+---/ \_\
                                            / |    `  ||/
"A ship in a harbour is safe, but that     /  ||`----'||
is not what ships are built for."             ||      ||
                     - John Parks             ``      ``

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

Date:    Mon, 04 Feb 91 13:18:00 -0500
From:    John Perry KG5RG <[e-mail]>
Subject: SIGN.TXT Update available on BEACH (PC)

FYI,

        The new signature file update for Fridrik Skulason's F-PROT114
is available by anonymous FTP at beach.gal.utexas.edu (129.109.1.207).
It is in the anonymous/pub/virus/pc directory and is entitled
VIRUS.NEW. If you have any questions you can contact me at the
following addresses.  --

                              John Perry KG5RG
                              University of Texas Medical Branch
                              Galveston, Texas  77550-2772

You can send mail to me at any of the following addresses:

DECnet   : BEACH::PERRY
THEnet   : BEACH::PERRY
Internet : [e-mail]
Internet : [e-mail]
BITNET   : PERRY@UTMBEACH
SPAN     : UTSPAN::UTADNX::BEACH::PERRY
FIDOnet  : 1:106/365.0

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

Date:    05 Feb 91 14:17:55 +0000
From:    [e-mail] (Werner Icking)
Subject: FPROT114 & SORT conflicting (PC)

After installing DEVICE = C:\QEMM\LOADHI.SYS /R:2 C:\DOSPRV\F-DRIVER.SYS
                                                            ^^^^^^^^^^^^
from FPROT114.ZIP I cannot use SORT.EXE. If I call SORT the PC hangs. If I
call it under MS-WINDOWS 3.0 I'm able to switch to the programm-manager. If
I call then DOS once more I get a message about SHARING violation.

SORT.EXE belongs to MS-DOS 4.01 Rel 1.02. I do not use COMMAND.COM but 4DOS.

Is this problem reproducible? Any help, any explanation?

- --
Werner Icking          [e-mail]          ([phone]
Gesellschaft fuer Mathematik und Datenverarbeitung mbH (GMD)
Schloss Birlinghoven, P.O.Box 1240, D-5205 Sankt Augustin 1, FRGermany
                                  "Der Dativ ist dem Genitiv sein Tod."


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

Date:    4 Febuary, 1991
From:    Padgett Peterson <[e-mail]>
Subject: Hard Disks (PC)

[e-mail] (Russell A. Fink) writes
>On two IBM PC's, one, a PS/2 Model 50; the other, an AT (circa '86), I
>notice that 'chkdsk' on the hard drives result in there being an
>identical number (and memory cost) of 'bad sectors' reported for both
>machines.

        This is not surprising if the disks are similar and would
depend on the disk configuration and "bad tracks". Very simply, it is
not unusual a hard disk to have a few "bad tracks" reported. This
usually appears on a sheet supplied with the drive and on a label
attached to the drive. At one time, most drives I saw had zero while
today 2-4 is not unusual. If a 40 Mb drive had over 5 I would become
concerned though I once saw a 33 Mb EDSI drive with over 100
(really!).

        Normally, the label will report "bad" tracks by cyl and head
e.g. cyl 307 hd 5 and this should be entered into the "defects list"
when a low-level format is done such as by DISKMANAGER.

        Now on an MFM drive, there are typically 17 sectors per
cyl/head so when a "track" is marked bad, this represents 17 x 512
bytes or 8704 bytes.  However, when the disk is formatted, DOS
allocates in "clusters" made up of 2, 4, 8, or 16 sectors. Since if
any part of a cluster touches the bad track, DOS marks it "bad" in the
FAT so the real loss depends on the cluster size (Norton's DiskInfo or
any of a number of utilities can give you this information) so for
each bad track, DOS reports "bad sectors" as follows:

Cluster Size     Sectors Lost "Bad"     DOS Lost Bytes/"Bad" Track
     2                 18                    9,216
     4                 20                   10,240
     8                 24                   12,288
    16                 32                   16,384

Thus for 4 sectors / cluster, each "track" marked bad will have CHKDSK
report a loss of 10,240 bytes, if four heads are reported on the "bad
track" list, CHKDSK will report a loss of 40,960 bytes. This would not
be unusual and could be verified by examination of the disk or use of
a non-destructive disk analysis utility such as Steve Gibson's
SPINRITE. What would be unusual would be the loss of a different
sector quanta such as 2 - 4 sector clusters or 4096 bytes.

Note: If you use DEBUG to look at the boot sector (-L 100 2 0 1), the
      cluster size may be found at offset 0Dh (debug command -e10d). If you
      see a 10, remember this is hex (16).
                                                Padgett

            ps: my partition table replacement is now in beta.

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

Date:    Tue, 05 Feb 91 14:46:03 +0000
From:    [e-mail] (Per Goetterup)
Subject: Re: Word Perfect and change checkers (PC?)

[e-mail] (Kip J Mussatt) writes:

=>If I am understanding you correctly, WP 4.2 and later versions should
=>be virus proof?

Not true! - We've had an Invader infection here on DIKU (Dept. of
Computer Science, University of Copenhagen) and it infected both
WP.EXE and PTR.EXE of version 5.1 without problems, and both programs
did run after infection!

It did ask if another copy of WP was running, but otherwise nothing.

        Happy (virus)hunting!

                Per.
- --
| Per Gotterup                        | "The most merciful thing in the    |
| Student, DIKU (Dept. of Comp. Sci.) | world, I think, is the inability   |
| University of Copenhagen, Denmark   | of the human mind to correlate all |
| Internet: [e-mail]    | its contents."  - H.P. Lovecraft - |

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

Date:    04 Feb 91 00:00:00
From:    Padgett Peterson <[e-mail]>
Subject: Low-Level Protection (PC)

[e-mail] (Rob Slade) writes concerning "boot sector
protection":
>It would not, unfortunately, deal with "stealth" boot viri like Joshi, and I
>can see virus writers getting around it in other ways as well.

        I must disagree though the boot sector is a difficult place to
put it and all sorts of housekeeping would be required. The partition
table on the other hand is a nice place. The "stealth" viruses (JOSHI
et al) operate by redirecting low-level interrupts to return only
uninfected code.  To do so, they must go resident in RAM. Once the OS
loads, this is very difficult to detect since each OS does its own
redirection. Prior to the OS load however, only the bare BIOS or ROM
extension interrupts are available and these can be verified very
easily and are sufficient to detect such attacks immediately.

                                                Padgett

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

Date:    Tue, 05 Feb 91 20:37:30 +0000
From:    [e-mail] (Anup C. Patel)
Subject: Virex 3.0 INIT problem (Mac)

There have been reports from users of Virex 3.0 and Moire screen saver
conflicting.  Specifically, when the Diagnose Disk when Mounted option
is set to ask for user permission, Moire does not show the dialog box
if it is active.  Moreover, the disk does not even show up on the
desktop.

Doing the <Command><Shift><1> does eject the disk however.  Anyone
else have this problem??

Thanks.

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

Date:    Tue, 05 Feb 91 22:26:45 +0700
From:    "J.C." Kohler <[e-mail]>
Subject: WP and change checkers, it goes on (PC)

Rob Slade writes:

>>All versions of Word Perfect (at least since 4.2) have had a self
>>testing module on them.  Neither F-XLOCK nor SCAN /AV nor any other
>>slef checker that adds code to the program can be used on it, since
>>the added code invalidates the internal self test.

Kip J Mussatt writes

>If I am understanding you correctly, WP 4.2 and later versions should
>be virus proof?  If this is your assumption then why did we have an
>epidemic of the Jeru II virus that infected almost every wp 4.2, 5.0,
>and 5.1 at work?  Again, if I am misunderstanding what you are saying
>about WP product, then please clarify.  If not, then could you please
>shed some light on my question. Thanx

Here comes the reply I got from Mr. Skulason himself

>Date:    30 Jan 91 11:55:51 +0000
>From:    [e-mail] (Fridrik Skulason)
>Subject: Re: Problem with F-Prot 1.14 (PC)

>This problem is a side-effect of the correction of another problem.
>Here is what happened:

>The "length" of EXE files can be defined in two ways - the actual (physical)
>length of the file, and the length according to the header.  Case in point:

>Turbo C++ is an 800K file, but according to the header it is only 165K long.
>When it is executed, only 165K are loaded into memory, but the program may
>later load parts of itself as necessary.

>Using F-XLOCK (to add automatic detection of infection of unknown viruses)
>involves adding a small module to the end of the file.  If Turbo C++ was
>F-XLOCKed in this way, it would not run, as the resulting length of the file
>was 800K (according to the header), and the file just could not be loaded
>into memory.

Altough I received two mail messages saying that it was because of the
self checker in wp, I would say Mr. Skulason is right. I also heard of
viri infecting wp, Jerusalem and PingPong. Isn't it easy to build a
self-checker into a program ( as suggested WP has done )? I could
imagine that you just check the .exe when it is running, you could
play around with some XOR's to create a check. You could even put the
value in a seperate file, as long as your checking algorithm is
complexe enough.

Christian

[J.] Christian Kohler
Keele university, United Kingdom
JANET    : [e-mail]1
INTERNET : [e-mail]
BITNET   : csw76%keele.ac.uk@ukacrl
UUCP     : ..!ukc!keele!csw76

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

Date:    Wed, 06 Feb 91 01:55:05 -0500
From:    [e-mail] (Jun Guo)
Subject: Compressors

Hi,

   We know that signature based scanner will not search into compressed
EXE/COM file. So if we have decompressors we should decompress the file
and then apply virus scanner on it.

   The following is a list of EXE/COM compressors I heard of:
   compressor:                    decompressor:
      LZEXE                         UNLZEXE
      PKlite                        PKlite -x
      Diet 1.0                      Diet -r
      LEXEM
      TinyProg
      EXEPACK                       UPACKEXE
      AXE
      Shrink
      SCRNCH
      ICE                           ICE breaker
      CRUNCH

   I'd like to hear from you of other compressors and decompressors.

   And one more thing: how are device drivers loaded? Can they be
compressed also? If yes, how can we decompress that?

   Many thanks.

Jun

P.S.: I just heard of there is ICE breaker. But never seen that.

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

Date:    Wed, 06 Feb 91 09:58:04 +0000
From:    [e-mail] (Where there is darkness, light)
Subject: Re: Hardware damage?

[e-mail] (Jody Hagins) writes:

>Please forgive my ignorance on this subject...

>Is it possible for a virus, etc to cripple physical hardware
>components?  I ask as I have recently experienced an abrupt halt of my
>system, frying my power supply.  This occurred after aquiring a piece
>of software from a supposedly very reliable source.  Just wondering if
>this is related, or a coincidence.

>Thanks for any help!

I have a book on assembly language programming of the PC video
hardware which includes a caution against certain programming mistakes
to avoid when setting up the video controller.

It claims that you can actually physically damage a monitor from
within software.  Needless to say I haven't tried it to see if it's
really true.

I don't know about other components.

Kris.
- --
Kriston M. Bruland          |    . .         . .      . . .      .       . .
[e-mail] |    .   .     . .        .        . .       .   .
[e-mail]   |    .             .         .     .   .     .

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

Date:    05 Feb 91 17:12:44
From:    [e-mail] (Rick Keir, MACC)
Subject: Easy way to write protect 3.5" disks

I've seen several references to prying out the write protect
tabs of a 3.5" disk to render it permanently read-only.

This is a lot of work, especially as some disks are not real
well heat-sealed;  the entire case has a tendency to split
(while the write tab stays stubbornly in place).  Any
kind of styrene cement will work just fine for gluing
them in the "open" position.

Personally, I like Testor's tube cement;  this is basically a
version of the liquid stuff with a lot of plastic already
dissolved into it, so that (1) it flows slower, (2) it acts
less rapidly, and (3) it doesn't kick as much junk into the
air when it is setting.  The smell might put some people
off (I stick 'em shut in my office, then leave them to dry
while I'm elsewhere);  if you've ever built models you probably
won't mind it.

By the way, if you do want to remove the tab permanently, just
use a generous amount of the liquid version:  this will dissolve
the entire corner of the disk case and the tab may easily be
removed.  I know this works from (unintentional) experiment :).

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

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