VIRUS-L Digest Monday, 29 Jul 1991 Volume 4 : Issue 132
Today's Topics:
Re: F-PROT configuration question (PC)
Re: F-PROT & DOS 5.0 (PC)
CARO and EICAR
Re: viruses in the press
Re: F-PROT & DOS 5.0 (PC)
Re: Index of Known Malware: 998 viruses/trojans
Re: F-PROT & DOS 5.0 (PC)
ScanV57 & Stoned alarm (PC)
Re: Self-scanning executables (PC)
Dark Avenger (PC)
Re: Virus Scan V57 and V77. (PC)
Index of Known Malware: 998 viruses/trojans
Re: HighMemory(even longer & more technical) (PC)
Re: Philosophy, comments & Re: longer and technicaller
Re: High Memory (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
[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: 26 Jul 91 08:01:08 +0000
>From:
[email protected] (Fridrik Skulason)
Subject: Re: F-PROT configuration question (PC)
The configuration of F-PROT will change a bit with the soon-to-be released
version 2.0.
Instead of loading F-DRIVER.SYS from CONFIG.SYS and running F-NET.EXE after
the network software is loaded, the programs have now been combined into
one: VIRSTOP.EXE
This program is loaded from AUTOEXEC.BAT, so...
(for) On a network, a single copy can now be kept on the server, instead
of having to update each individual machine, when a new version is
released
(against) F-DRIVER.SYS was more-or-less immune to infection, being a device
driver, and it could prevent an infected COMMAND.COM from running.
VIRSTOP.EXE may become infected, if it is run after an infected
program. It performs a very good self-test, however, so it will
even detect an infection by a sophisticated "stealth" virus, such
as Frodo.
I have just received a report of one strange conflict regarding
F-DRIVER/F-NET. If run on a Novell network, with a certain version of
Netware, and the user is running Windows, and either Excel or Word for
Windows, and attempting to print to a laser printer, the output will
become garbled. Switching to a copy of Netware, with a slightly
different size and date, but the same version number solved the
problem. I don't have an explanation, but I would very much like to
hear from anyone else who encounters this problem.
- -frisk
------------------------------
Date: 26 Jul 91 08:03:46 +0000
>From:
[email protected] (Fridrik Skulason)
Subject: Re: F-PROT & DOS 5.0 (PC)
[email protected] (Lou Anschuetz) writes:
>Installed DOS5.0 on my machine last night (which works well imho),
>but ran into a problem with F-PROT. If I attempted to leave the
>F-PROT driver.sys in my config.sys file the machine would freeze
>and complain that INT13 was modified (undoubtedly true). Has
>anyone found a work-around for this?
There are three possible solutions, one of which should work on your
machine.
1) load F-DRIVER with DEVICEHIGH=
2) load F-DRIVER last in CONFIG.SYS
3) load F-DRIVER with DEVICE=F-DRIVER /NOINT
(this undocumented switch disables the interrupt check).
- -frisk
------------------------------
Date: Fri, 26 Jul 91 14:25:28 +0200
>From:
[email protected]
Subject: CARO and EICAR
In "Der Aarbote" 1991-04-19, a local newpaper, the founding of two
anti-virus organizations was anounced. Here's a short excerpt from
this article (the original text isn't as clumsy as my translation
B-]):
"To avoid unneccessary double work, leading virus experts in europe
founded two international organizations: with CARO (Computer Antivirus
Research Organization), the scientists want to coordinate their
anti-virus-work; EICAR (European Institute for Computer Anti- Virus
Research) is the organization of the commercial software developpers.
CARO and EICAR will be located in Brussels. The most important goal is
to develop a common language to describe computer viruses and to
inform each other about new viruses".
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?
Christian Treber
`___'
/- -\ "Big brother is writing you!"
\ | /
[email protected]
\-/ Christian Treber, FRG, FH Fulda, FB Telecommunications
------------------------------
Date: Fri, 26 Jul 91 02:27:40 -0500
>From: Paul Coen <
[email protected]>
Subject: Re: viruses in the press
Well, all I can say is that in a document that I wrote for the Drew
University Academic Computer Center (and I think that the department
that hands out freshman computers included it in their fresman
handbook) started out by saying that you should forget what you've
heard about viruses from the press, since too much of it is
inaccurate.
Okay, we can't expect the press to be perfect. We can expect them to
at least make an effort. And in fields that I'm pretty well-versed
(computers, cultural & physical anthropology, sociology, etc.),
they're horribly inaccurate. People I've talked to in other fields
have complained about reporting in their areas -- incorrect in ways
that shouldn't have happened if the person either writing or editing
the story had even taken an intro course in that field or a related
field.
I'd say that asking "people in the know" -- establishing contacts in
various fields would help, except that often times newspapers don't
even quote correctly, or attribute the quotes to the correct people.
An example: during the Morris worm incident, a reporter from the
Newark Star-Ledger in NJ called the Academic Computer Center, and
talked to my boss, his boss, and a student programmer about it. We
all knew about it, because we'd read everything that had come in over
the net about it, so we told her what we knew. My boss told her that
it wasn't a virus. In her story, she called it a virus. She then
went on to not use quotes from my boss (Neil) but from his boss (Bill)
but proceeded to attribute the quote to Neil.
Moral of the story: the press makes mistakes. Okay, again, they're
human. But if "journalists" can't report properly or put a reasonable
perpective on an event or topic, shouldn't papers and news
organizations be hiring more people who understand the technology AND
can communicate? There are a few of us out here. There are quite a
few on this list :).
If you're a journalism student, and want to pick a bone with me, go
ahead. Just don't EVER write a factually incorrect story about
computers or anthropology in a paper I read :).
- ----------
Paul Coen --
[email protected],
[email protected],
[email protected]
Disclaimer: These ARE my opinions -- I've been taking the summer off.
------------------------------
Date: 26 Jul 91 11:41:31 +0000
>From: M I Clarkson <
[email protected]>
Subject: Re: F-PROT & DOS 5.0 (PC)
I found problems with F-PROT's F-DRIVER.SYS and DOS 5.0 too. The
cause of the problem on my machine seems to have been HIMEM.SYS. It
modifies INT 13, doesn't it? Anyway, try moving F-DRIVER.SYS to just
after HIMEM.SYS in your CONFIG.SYS file. My machine now boots OK, and
traps F-TEST OK.
Mike.
------------------------------
Date: 26 Jul 91 21:09:49 +0000
>From:
[email protected] (Shoou-yu tang)
Subject: Re: Index of Known Malware: 998 viruses/trojans
[email protected] (Klaus Brunnstein) writes:
>VTC documents (Index of Known Malicious Software: IMSDOS.791; Index of Virus
>Catalog: Index.791; all entries classified up to now) are now available from
>FTP:
> Our FTP server: ftp.rz.informatik.uni-hamburg.de
Does anyone has the Internet IP # for this site?
Our system does not have a table link to this address and local name server
can't find it too.
Thanks
Tang
[email protected]
[Ed. See follow-up below.]
------------------------------
Date: Fri, 26 Jul 91 14:01:37 -0700
>From:
[email protected] (Rob Slade)
Subject: Re: F-PROT & DOS 5.0 (PC)
[email protected] (Lou Anschuetz) writes:
> Installed DOS5.0 on my machine last night (which works well imho),
> but ran into a problem with F-PROT. If I attempted to leave the
> F-PROT driver.sys in my config.sys file the machine would freeze
> and complain that INT13 was modified (undoubtedly true). Has
> anyone found a work-around for this?
I was able to find workarounds on two different machines. On one,
booting off the A: drive, with a normal CONFIG.SYS, fixed the problem.
On a PS/2, this did not work. I was able to get it too work by invoking
F-DRIVER.SYS after the HIMEM.SYS.
Other ideas about "loading high" did not seem to work in this case. Here
is the relavent section of the CONFIG.SYS file:
rem devicehigh=c:\vir\fpr\f-driver.sys **hangs
rem device=c:\vir\fpr\f-driver.sys **hangs
rem device=c:\vir\fpr\f-driver.sys /noint **works
break=on
FILES=50
BUFFERS=32
LASTDRIVE=w
FCBS=16,8
shell=c:\command.com c:\ /p /e:1024
rem device=c:\vir\fpr\f-driver.sys **hangs
device=C:\dos\himem.sys
device=c:\vir\fpr\f-driver.sys
rem device=c:\dos\emm386.exe noems x=d000-d3ff
devicehigh=c:\dos\setver.exe
devicehigh=c:\dos\smartdrv.sys 2048 1024
=============
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: Sat, 27 Jul 91 09:40:14 -0400
>From: Tom Young <
[email protected]>
Subject: ScanV57 & Stoned alarm (PC)
Andrew Brennan of Drexel writes:
> I've an interesting problem at the center I am working for.
> Apparently, SCAN stops checking memory for Stoned after V57. We
> have V57 (in normal use) and can locate Stoned in memory, but it
> is not found on the disks - hard disks or otherwise. After we
> reset the machine (booting from the hard disk), we have Stoned
> in memory again - not located on the hard disk.
> ...
Are you perchance running AppleShare PC? I seem to remember deciding
that the combination of ScanV57 and AppleShare 2.0 (but not 2.1?)
yielded a false positive for Stoned in memory. This would also
explain why you don't get an alarm when booting from a clean diskette
(AShare stuff not loaded). I never posted this tidbit since one or
both of the above versions of these products were outdated at the time
of my discovery :-).
Tom Young, Cornell Information Technologies, Workstation Systems Services
Bitnet: XMU@CORNELLA Internet:
[email protected]
------------------------------
Date: 27 Jul 91 14:39:55 +0000
>From:
[email protected] (Fridrik Skulason)
Subject: Re: Self-scanning executables (PC)
[email protected] (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.
Well, this is of just as much use as a simple checksumming algorithm -
it is very unlikely that a virus will attempt to atteck the encryption
algorithm itself - trying to "fake" the CRC. A much more effective
method is to use "stealth" techniques.
If the implementation of this algorithm detects infection by Frodo
(4096), it is worth considering...
- -frisk
------------------------------
Date: 28 Jul 91 02:05:34 +0000
>From:
[email protected] (
[email protected])
Subject: Dark Avenger (PC)
Hello,
I just discovered that my hard drive has been affected by the Dark
Avenger Virus. I dutifully downloaded a few of the scanners and
disinfectants from wuarchives. With the McAfee software (7.6v80), I
was told the the DA was there and then I used clean to remove it.
When I then run scan, it tells me all is well. So, I power down and
reboot from my hard drive (having used a clean floppy before). Now
scan tells me the the DA is present in memory again.
Am I doing something wrong? missing a step? Thanks for any help you
can give.
Pat
- --
Pat Sine
[email protected]
Instructional Technology
Willard Hall Ed. Bldg., University of Delaware, Newark, DE 19716
------------------------------
Date: Sun, 28 Jul 91 04:40:20 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: Virus Scan V57 and V77. (PC)
[email protected] (Andrew Brennan) writes:
> I've an interesting problem at the center I am working for.
> Apparently, SCAN stops checking memory for Stoned after V57. We
> have V57 (in normal use) and can locate Stoned in memory, but it
> is not found on the disks - hard disks or otherwise. After we
> reset the machine (booting from the hard disk), we have Stoned
> in memory again - not located on the hard disk.
> My immediate assumption was that it was a strain of Stoned
> that was not locatable by the old version - but the basic shape
> of Stoned was locatable in the memory of the machine. Upon a
> boot from a clean disk, no Stoned anywhere. I dug out a copy of
> V77 (assuming/hoping that it would locate the virus on the disk)
> only to find that V77 no longer memory-scans for Stoned. I also
> found that V77 was unable to find Stoned on the same harddisk.
> We don't have V80 and I was unable to retrieve a copy via the
> Internet as there was/is some problem out there that was not
> allowing access outside this site - some server was down ...
> We tried (a suggestion from an outside source) optimizing the
> hard disk - to remove any phantom viral activities(?) V57 still
> finds Stoned in memory - not on the disk. V77 doesn't look for
> 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 ...
To tell VIRUSCAN (also known as SCAN) to check memory for the Stoned
virus, add the "/M" parameter to the command line, i.e., SCAN C: /M
(and press Enter)
It could also be that you are having a false alarm with some other
program in memory, or that the disk optimizing program didn't erase
the "ghost" left over after disinfection.
You may wish to look at the partition table of the disk with a sector
editor to determine if the virus is there. This would help rule out a
false alarm.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
Santa Clara, California | BBS (408) 988-4004 |
[email protected](personal)
95054-0253 USA | v.32 (408) 988-5190 |
ViruScan/CleanUp/VShield | HST (408) 988-5138 | CompuServe: 76702,1714
------------------------------
Date: Sat, 27 Jul 91 22:14:02 +0700
>From:
[email protected] (Morton Swimmer)
Subject: Index of Known Malware: 998 viruses/trojans
[email protected] (Klaus Brunnstein) writes:
> Catalog: Index.791; all entries classified up to now) are now available from
> FTP:
> Our FTP server: ftp.rz.informatik.uni-hamburg.de
> Login anonymous
> ID as you wish (preferably your name)
> dir: directory of available information
> cd pub/virus: VTCs documents
Sorry, the address should have read:
ftp.informatik.uni-hamburg.de
As the directory's moderator, I would ask everyone to first look for
the information at a site nearest you. We are very far off the
internet and suffer from a low load line (9600 BAUD) that is also used
for other things.
Cheers, Morton
[Ed. The DNS-registered IP numbers for this site are: 134.100.4.42 and
188.1.20.32.]
.............................................................................
morton swimmer..odenwaldstr.9..2000 hamburg 20..germany..tel: +49 40 4910247.
internet:
[email protected] or
[email protected].
.............to leave only footprints, and take only memories................
------------------------------
Date: Mon, 29 Jul 91 16:25:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: HighMemory(even longer & more technical) (PC)
[email protected] (Keith Rohrer) writes:
> One thing that I will agree that is if nothing is loaded high, it isn't
> a virus, especially if you stopped things from loading high by axeing
> the memory manager from your CONFIG.SYS.
It is possible for a virus (admittedly, a pretty large virus) to be
loaded above A0000 even without one of the memory managers you
mentioned, but it does require certain hardware to be present. The
obvious way is to provide its own control of the 386 or Neat 286
chipset or even just the A20 line. But, since most people who buy such
hardware are hardly likely to have it without using such software to
get the best value out of it, such a virus is likely to conflict, and
the system would crash. Also, a virus could try to live in the extra
RAM on a vidoe card (the Hercules card has plenty), or the RAM on some
network cards, etc... again, they would, in all probability, be
overwritten as soon as you use some programs, but it is theoretically
possible.
There are ways of checking that the code is ROM rather than RAM which
are easy to implement. I suggest that anyone tracing through memory
for a code segment greater than C000 should also check that it points
to ROM by trying to write something to it (with interrupts turned
off).
The machine I'm using now, for instance, has at least two chunks of
code up there grabbing the int 13 vector in addition to the BIOS.
Mark Aitchison.
------------------------------
Date: Mon, 29 Jul 91 16:54:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Philosophy, comments & Re: longer and technicaller
[email protected] (John Francis) writes:
> BUT - on 386 or better systems, I can write a "Virtual Machine" emulator
I was hoping nobody would mention that possibility. It is a risk
saying too much, in case virus writers get ideas, but also a risk in
not alerting people to the possibility (e.g. I wonder if I should
*really* have mentioned that it is possible to get a virus from just
listing files in a directory?). Hopefully, that and the present idea
won't be too successful for virus writers, because they need a good
number of receptive systems to spread effectively.
For anyone worring about viruses taking advantage of 386 features,
here are a few thoughts to balance it with...
(1) Think of the size of the virus, what difference it would make to files or
disks it tries to infect - surely obvious even to uneducated users.
(2) Most people with a 386 will now be using MS- or DR-DOS 5 (or whatever) to
take adavantage of the hardware - such software at present might not be smart
enough to say "hey! there's a virus here already" but will probably crash.
(3) there are few ways of detecting it - especially when you know information
about the computer from the time it was virus-free. For one thing, exact
timings of some operations would be a big clue.
(4) if Microsoft, Digital Reasearch and others have any sense, THEY will use
the hardware to beat the viruses, instead of the other way around. Whoever -
virus writers or O/S writers, take control first and best, will win - or at
least make it extremely difficult for the opposition.
(5) I've run a checking program on a Sparc emulation of an AT, and noticed the
difference (I didn't even write the program with that system in mind) - any
virtual machine running under a 386 would be even easier to detect, given the
speed considerations - i.e. a 386 cannot emulate a 386 of the same clock speed
without making the extra time in hardware traps, etc obvious).
I said a long time ago that boot sector viruses are essentially
doomed; the ability to detect and stop* them will always be greater
than file viruses (given PC's of today and the near future). I may
have sounded very pessimistic about whether file viruses or anti-virus
measures will win in the long run (mainly because there are so many
programs that do just about the same things as a virus) - but really
good software in control of a 386 or better gives me, at least, a lot
of hope. Now come on, MS & DR guys! write it before the virus writers
use the loopholes, please!
Mark Aitchison.
* if you have more questions about a-v software beating *any* boot sector
virus, feel free to e-mail me.
------------------------------
Date: Fri, 26 Jul 91 12:39:21 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Re: High Memory (PC)
>From:
[email protected] (Keith Rohrer)
>From: "William Walker C60223 x4570" <
[email protected]>
Both writers make valid points concerning the "high memory areas"
available for DOS on modern (80286-up) platforms and the potential for
viral activity to use these areas. However, integrity management is
possible, even in this specialized environment.
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).
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). While QEMM and others use the B000h-BFFFh
area in some cases for high menory, this does not occur until after
DOS & the memory manager loads. The only exception to this that I know
of is certain expanded memory boards designed for XT class machines
that incorporate the LIM page frame and use onboard ROM extenders for
access.
Since everything in this region is, in theory, ROM and unwritable
(easily checked if necessary), verification is simple.
- ---------------------------------------------------------------
ANFSCD:
>From: padgett%
[email protected] (A. Padgett Peterson)
> ... a response was posted to another comment that you must boot
> cold from an infected floppy before trust is possible even if a
^^^^^^^^
> clean Int 13 (disk access) path is known.
EEP! er, ah, that is...oops. Mr. Walker is of course entirely correct,
that should be "boot cold from an uninfected, write protected" floppy.
Padgett
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 132]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
