VIRUS-L Digest Wednesday, 31 Jul 1991 Volume 4 : Issue 133

VIRUS-L Digest Wednesday, 31 Jul 1991 Volume 4 : Issue 133

Today's Topics:

Brunnstein (CARO) virus catalog files
Re: Exchanging floppies
Re: Philosophy, comments & Re: long and technical (PC)
Re: Virus Scan V57 and V77. (PC)
Dark Avenger (PC)
Tequila virus and partition table (PC)
Re: High Memory (PC)
Multi-compress
virues in io.sys (PC)
Re: Self-scanning executables (PC)
Observation on F-DRIVER.SYS & Windows 3 (PC)
CARO and EICAR
Re: Philosophy, comments & Re: long and technical (PC)
Re: Self-scanning executables (PC)
Related Terms

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 [email protected] (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: [email protected].

Ken van Wyk

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

Date: Mon, 29 Jul 91 16:32:27 -0400
>From: Kenneth R. van Wyk <[email protected]>
Subject: Brunnstein (CARO) virus catalog files

The files which Dr. Brunnstein announced on 24 July 1991, along with
the rest of the virus information files from CARO, are now available
on cert.sei.cmu.edu (IP number 192.88.209.5) in the
pub/virus-l/docs/brunnstein directory. Please use this archive rather
than ftp.informatik.uni-hamburg.de in order to limit the network load
to that site.

My thanks to the folks at CARO for making this excellent work freely
available.

Ken

Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
[email protected] (work)
[email protected] (home)
(412) 268-7090 (CERT 24 hour hotline)

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

Date: Mon, 29 Jul 91 17:37:42 -0400
>From: Peter Jones <[email protected]>
Subject: Re: Exchanging floppies

On Thu, 11 Jul 91 11:24:58 -0400 you said:
>I work in a library in which we have been accepting disks from patrons
>in exchange for a formatted disk. They then use those in our CD-ROM
>workstations to download. We re-format the disks we receive to use in
>the exchange process. To date, we have not had any infections
>(acording to virscan and f-prot). My question is this: would we be
>better off zapping the disks in the demagnitizer, then formatting? Or

I think formatting is enough. However, zapping is a great way to let
people know the data are going to be zapped forever. Also, you avoid
the problem of a disk slipping past the formatting station without
really being re-formatted (if someone is in a hurry and doesn't want
to wait for re-formatting).

Note that there are high-speed programs for copying/formatting a large
number of disks.

De-gaussing is also necessary if a DD disk has been accidentally
as HD, and you need to format at 2D on an HD drive.

Peter Jones (514)-987-3542
Internet:Peter Jones <MAINT%[email protected]>
UUCP: ...psuvax1!uqam.bitnet!maint
N.B.
"Our customers will forgive a one-time error far more quickly than they will
forgive our inability to correct that error." - Karen Ward ([email protected])

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

Date: 29 Jul 91 19:28:20 +0000
>From: [email protected] (Wm E Davidsen Jr)
Subject: Re: Philosophy, comments & Re: long and technical (PC)

[email protected] writes:

| One problem that may occur is that of BIOS-shadowing. We can no longer
| assume that the BIOS is in ROM at the time that it is executed. Many
| machines now copy it to faster RAM. It is possible that a virus might
| intercept the BIOS call inside the BIOS itself rather than in the
| interrupt table.

Which braindead machines do that? I know about BIOS shadowing, but I
don't think I've ever found one which didn't set write protect so memory
maps would think it was ROM.
- --
bill davidsen ([email protected] -or- uunet!crdgw1!crdos1!davidsen)
GE Corp R&D Center, Information Systems Operation, tech support group
Moderator comp.binaries.ibm.pc and 386-users digest.

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

Date: 29 Jul 91 16:15:46 +0000
>From: [email protected] (Bill Dyer)
Subject: Re: Virus Scan V57 and V77. (PC)

[email protected] (Andrew Brennan) writes:

> Stoned in the memory _and_ doesn't find it on the disk. I will
> be retrieving a copy of V80 ASAP, but I don't know exactly what
> to think in this situation ...
>
> Andrew. (brennaaa@duvm) Drexel Univ. College of Info Studies.

My version of SCAN (V77) found Stoned on my hard disk, no problem. It
was in the partition table. I would check your version of SCAN to
make sure it is clean. There was talk of a trojan version of SCAN,
but this was supposedly SCAN V78. If you have a program that will let
you look at the disk (PCTOOLS or Norton), look at your partition table
or boot sector. If you have Stoned, you should see the string "You
have been Stoned" or something like that. At least I did when I was
infected.

While I am here, a question about Stoned. From what I can tell,
Stoned is a memory resident program that resides in the partition
table on hard disks and the boot sector on floppies. My question is
what triggers the thing to infect a floppy from the hard disk? In
other words, what interupt is it stealing? Second question, can
Stoned infect other places besides the partition table? We have a PC
board plugged into one of our suns here at work, and I think the thing
is infected with Stoned. However, the thing does not have a standard
hard drive, I think it uses NFS and a partition on the Sun's hard
drive. The disk does not seem to have a partition table or a boot
sector that I can find? Does anyone know how these PC boards in a Sun
work, and if it would be possible for Stoned to infect one of them.
Thanks for any help.

- -Bill Dyer
- --
_____________________________________________________________________________
| I wish I could sit on soft pillows, |Bill Dyer (708) 632-7081 |
| and eat molten lava. | [email protected] |
| -King Missle | or uunet!motcid!dyer |

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

Date: 30 Jul 91 02:11:54 +0000
>From: [email protected] (Stefan Kozlowski)
Subject: Dark Avenger (PC)

Folks,
A friend of mine just called me and asked for help with
removing the Dark Avenger virus from his PC. I know nothing about the
virus and little about PC's. Any information would be greatly
appreciated.

Thanks in advance.

- --Stefan Kozlowski
MIT AI Lab
[email protected]

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

Date: 30 Jul 91 05:03:40 +0000
>From: Lachlan Brown <[email protected]>
Subject: Tequila virus and partition table (PC)

A friend of mine who works in a computer shop has recently had a
number of people coming to him with the Tequila virus on their systems.

In case I have a nasty encounter with it I'd like to know a little more.

If I understand correctly, the virus writes it's self in to the partition
table (as well as exe files and some other area of the hard disk)

Where exactly is the partition table? and is it changed or over
written in the a normal day on the computer, or can you back it up
using debug or whatevero in case some nasty groobly gets into it ?

Thanks in advance
Lachlan Brown
The University of Queensland
Electrical Engineering

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

Date: 30 Jul 91 10:44:00 -0500
>From: "William Walker C60223 x4570" <[email protected]>
Subject: Re: High Memory (PC)

>From: padgett%[email protected] (A. Padgett Peterson)

> The key is that at BIOS load time (before DOS), all Intel iapx80X86
> processors are running in real mode (i.e. brain-dead as a 8086).

Yep.

> There should be no "high" or "extended" or "expanded" RAM available
> as yet and all interrupts "should" be located in the segment range
> C000h-F000h. This is easily authenticated with a fast pass through
> the interrupt table since the segment prefix is in each vector. (the
> video buffer A000h-BFFFh) is a data storage area and should not have
> interrupts pointing there).

You cannot look only at the segment prefix to determine where the
vector points; you must calculate the actual address. For example, if
you found the segment 9800h, you might assume that the vector pointed
into the top of the 640K RAM area. But if the offset was 8000h,
making the entire address 9800:8000h, it would point to absolute
address 0A0000h, or the beginning of the video buffer. True, there
should be no vectors pointing into any RAM, video or otherwise, before
DOS is loaded. However, there is a more subtle example.

There is a portion of extended memory on a '286 or '386, which
Microsoft calls the High Memory Area (HMA), which is accessible from
real mode. A good explanation of how it works is given in the article
"Power Programming" by Ray Duncan, in the June 27, 1989 issue of PC
Magazine, part of which I've quoted below:

> "Recall the method by which physical addresses are generated in real
> mode. The contents of a segment register are shifted left 4 bits
> and added to a 16-bit offset. On an 8086/88 machine, if the result
> overflows the 20-bit addresses supported by the CPU, the address
> simply wraps--that is, the upper bits are discarded. 80286- and
> 80386-based PCs can support larger physical addresses (24 bits and
> 32 bits, respectively), but this capability is ordinarily not
> apparent when DOS is running. That's because these machines have
> special hardware to disable the most-significant address lines in
> real mode, making the machine behave more like an 8088.

> "Consider what happens, however, on an 80286 when you enable the A20
> line and place the value FFFFh in one of the segment registers.
> Enabling the A20 line allows the generation of 21-bit physical
> addresses. And when FFFFh is shifted left 4 bits and added to a
> 16-bit offset, the result will fall in the address range FFFF0h-
> 10FFEFh. In other words, enabling the A20 line allows the first
> 65,520 bytes of extended memory to be addressed WITHOUT LEAVING REAL
> MODE." [my emphasis - WWW]

> - Duncan, Ray. Power programming. PC Magazine, V8 I12 (June 27,
> 1989), p. 321. Copyright Ziff-Davis Publishing Co. 1989

Knowing this, suppose a virus has somehow infected a machine with a
pre-DOS validator, relocating it as though it was a normal boot sector
or MBR. Also suppose that it has enabled the A20 line and stored part
or all of itself in the HMA, with vectors pointing up there. These
vectors would by necessity have a segment prefix greater than 0F000h.
Now, when the validator gets control, it would mistakenly believe that
those vectors pointed into ROM below the 1M line if it only examined
the segment prefix. But if it calculated the full absolute addresses,
it would easily see that the vectors pointed into the HMA, not ROM.

Such a virus, though possible, would not be very viable, since running
HIMEM.SYS or anything which used memory in protected mode would wipe
out the virus code in the HMA. And, if the virus somehow protected
itself, these programs would bomb out, giving the user a clue that
something was wrong.

One other item: there is a device I mentioned in a previous posting
called the HIcard from RYBS Electronics. I'm not completely familiar
with this device, but I believe it adds 64K to conventional memory,
making a total of 704K. I believe it also puts that memory in an
unused block between 0A000h and 0F000h. At first, it seems like a
device few people would use, but it is mandatory on 8086/88/286
systems to run dBASE IV 1.0 with most networks, so there could be
quite a few in use. And there's nothing to prevent a virus from using
it at any time, even before DOS loads......

Disclaimer: The quoted material from A. Padgett Peterson belongs to
him. The quoted material from PC Magazine belongs to Ziff-Davis
Publishing. The rest belongs to me. None of it belongs to my
employer.

Bill Walker ( [email protected] ) |
OAO Corporation | "... but as we say on Earth,
Arnold Engineering Development Center | c'est la vie."
M.S. 120 | - James T. Kirk
Arnold Air Force Base, TN 37389-9998 |

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

Date: Tue, 30 Jul 91 10:19:00 -0700
>From: [email protected]
Subject: Multi-compress

Dmitri Schoeman in VIRUS-L #129:
> If the "compressed" code is larger than the original code it will
> erase the temp file, and I am sure we are all aware of the
> non-permancy of the erase command,.....

Ah, so /that's/ it.

Good going, Dmitri... this is a point that had eluded me since I
generaly do my compressions in a RAM disk for speed.

Perhaps we can prevail upon the makers of such to do a WIPE olike
routine on the old files to prevent this kind of thing?

> Can anyone verify if the code is sufficiently changed by the above
> method?

In the method you describe, the code being changed isn;t the problem,
here; it's that the checkers such as SCAN won't look inside a nested
file. It would look at the first level, without de-compressing the
file inside, and therefore wouldn;t see a virus inside the nested
file.

Again, seems the only way to prevent this is to tamper proof the
PKLITE and LZEXE code.... Again, perhaps if we yelled loud enough...

I'm quite sure Phil Katz would at least be interested in such a proposal.

And another good idea is Padgett's..>>>.The answer, of course, is for
scanners to use a recursive technique for unravelling files and it
would be relatively easy to check. Eternal Vigilance and all that. <<
Perhaps both ideas are worth pursuing?

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

Date: 30 Jul 91 14:09:15 +0000
>From: [email protected] (Willi Grueber)
Subject: virues in io.sys (PC)

Ares there any viruses infecting io.sys and thus installing themselves
before DOS is started ?

Which virus-scanners check for infected io.sys files ?

Thanks
Hermann

[email protected]

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

Date: Tue, 30 Jul 91 17:56:16 +0000
>From: [email protected] (John Francis)
Subject: Re: Self-scanning executables (PC)

Somewhere on CompuServe, Kevin Dean writes:
> Cracking the algorithm is not a trivial task: a virus has one chance
> in four billion (2^32) of successfully infecting a program or, if it
> decides to fool the algorithm by changing the stored CRC, would lock
> up a 386 for hours bordering on days to find and change it.

Unfortunately this is nothing more than "Ignorance Protection". There
has to be some way of calculating the initial CRC when the program is
built - they don't appear in the executable by magic! This must be by
some method that is faster than exhaustive search, or else nobody will
use CRC protection. The same algorithms are available to virus
writers.

It won't take long to find the encryption code in an executable - the
techniques to do that can be found in all the current virus scanners,
and we must assume that most virus writers are conversant with these
methods, and could use them themselves to find the right spot.

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

Date: Tue, 30 Jul 91 15:47:37 -0600
>From: [email protected] (Richard W Travsky)
Subject: Observation on F-DRIVER.SYS & Windows 3 (PC)

I was recently given a Zenith 386 to use here at work. These come
pre-installed with Windows 3.0 and DOS 4.01. I had troubles getting
Windows to come up in enhanced mode. It would default to standard and
on startup would complain about not finding an application (when it
should not have even been looking for one in the first place). The
program manager window was small (not minimized, more like a window
onto a maximized window - hopefully you get the picture). And there
was a couple of other minor annoyances I've already forgotten about.

Any, I played the windows game, fiddling with my config.sys. What
worked was moving F-DRIVER.SYS towards the end of the device calls.
Anyone have any other Windows/fprot experiences? After the recent
posts about F-DRIVER.SYS and DOS 5.0 I thought it interesting enough
to pass on.

Richard Travsky
Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming (307) 766 - 3663 / 3668

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

Date: Tue, 30 Jul 91 09:42:15 -0700
>From: [email protected] (Rob Slade)
Subject: CARO and EICAR

[email protected] writes:

> I never read something about CARO and EICAR on this list. Does anyone
> have some information about this two organizations or other
> international efforts to fight computer viruses?

CARO is connected with Klaus Brunnstein, the primary contact for the
Computer Virus Catalogue project, and a fairly regular contributor.

=============
Vancouver [email protected] | "If you do buy a
Institute for [email protected] | computer, don't
Research into (SUZY) INtegrity | turn it on."
User Canada V7K 2G6 | Richards' 2nd Law
Security | of Data Security

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

Date: Fri, 26 Jul 91 17:08:44 +0000
>From: [email protected] (Martijn Nykerk)
Subject: Re: Philosophy, comments & Re: long and technical (PC)

Maybe a Followup WILL make it out of here.

Anyways [email protected] (John Francis) opposing padgett%[email protected]
(A. Padgett Peterson) on authenticatable peripheral paths writes:

> I do not, however, accept your belief that you can get clean and
> authenticatable periperal paths" on a PC.

> On 386 or better systems, I can write a "Virtual Machine" emulator
> that can fool you into believing you are running on the raw hardware.
> This means I can write the ultimate stealth system - undetectable by any
> means whatsoever (not quite true, but I don't want to give everything away).

I don't want to give everything away? (are you working on one? :) ;) :) )

Forgive me if I am wrong but wouldn't the check to see if you're at
ROM BIOS (if that's where you want to be) be just a memory write and a
check to see if your byte survived in the big world? Ofcourse
shadowing would sort of f*ck this check up I guess.

Martijn.

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

Date: Mon, 29 Jul 91 13:05:00 -0400
>From: Jeff Boyd <[email protected]>
Subject: Re: Self-scanning executables (PC)

Fridrik Skulason <[email protected]> wrote:
> Well, this is of just as much use as a simple checksumming algorithm -

You either overlook or underestimate the value of it. When I write PC
software for sale or otherwise, I build this routine in and the
program has an INDEPENDENT self-check CRC calculation. My program will
not run if altered, and hence will NEVER aid in the spread of a virus
(provided the user takes appropriate cleansing action when the program
finds any changes - the virus could certainly move in the single run
required to expose its presence).

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

Date: Fri, 26 Jul 91 14:13:25 -0700
>From: [email protected] (Rob Slade)
Subject: Related Terms

DEFGEN4.CVP 910721

Related (non-viral) terms

Two other groups of security breaking programs are very often
confused with viri. The first is the "trojan horse", the second
the "logic bomb." The confusion is understandable, as viral
type programs, trojan horses and logic bombs make up the three
largest distinct groups of security breaking software, and often
one may "contain" the code of one another.

A trojan horse is a program which pretends to do one thing,
while performing another, unwanted action. The extent of the
"pretence" may vary greatly. Many of the early PC trojans
relied merely on the filename and a description on a bulletin
board. "Login" trojans, popular among university student
mainframe users, will mimic the screen display and prompts of
the normal login program, and may, in fact, pass the username
and password along to the valid login program, as well as
stealing it. Some trojans may contain actual code which does
what it is supposed to be doing, while performing additional
nasty acts that it does not tell you about. (I make the
distinction that trojans are always malicious, as opposed to
"joke" or "prank" programs.)

(A recent example of a trojan is the "AIDS Information Disk",
often incorrectly indentified in both the general and computer
trade press as a virus. Not to be confused with the, fairly
rare, AIDS I and II viri, this program appears to have been part
of a well organized extortion attempt. The "evaluation disks"
were shipped to medical organizations in England and Europe,
with covers, documentation and license agreements just like any
real commercial product. When installed and run, it did give
information and an evaluation of the subject's risk of getting
AIDS, but it also modified the boot sequence so that after 90
reboots of the computer all files on the disk were encrypted.
The user was informed that, in order to get the decryption key,
a "license fee" had to be paid.)

Trojan horse programs are sometimes referred to as an "Arf, arf"
or "Gotcha" program from the screen messages of one of the first
examples. A trojan horse may be used to plant a virus simply by
infecting any existing program.

A logic bomb is a malicious program which is triggered by a
certain event or situation. Logic bomb code may be part of a
regular program, or set of programs, and not activate when first
run, thus having some of the features of a trojan. The trigger
can be any event that can be detected by software, such as a
date, username, CPU id, account name, or the presence or absence
of a certain file. Viral programs and trojans may contain logic
bombs.

copyright Robert M. Slade, 1991 DEFGEN4.CVP 910721

=============
Vancouver [email protected] | "If you do buy a
Institute for [email protected] | computer, don't
Research into (SUZY) INtegrity | turn it on."
User Canada V7K 2G6 | Richards' 2nd Law
Security | of Data Security

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

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

Downloaded From P-80 International Information Systems 304-744-2253