home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hacker 2
/
HACKER2.mdf
/
virus
/
virusl3
/
virusl3.73
< prev
next >
Wrap
Text File
|
1995-01-03
|
22KB
|
513 lines
VIRUS-L Digest Tuesday, 10 Apr 1990 Volume 3 : Issue 73
Today's Topics:
Gatekeeper 1.1.1 & Scores (Mac)
Disinfectant 1.7 and GateKeeper (Mac)
Re: Universal Virus Detector
Validate program corrupted?? (PC)
Low Level Format (PC)
Re: Validating Virus Software
Re: FTP from SIMTEL20 to VM/CMS (Internet)
What do I buy? (PC)
re: Universal Virus Detector
FTP and .hqx (Mac)
Re: Virus in Text Files (Mac)
Oops- wrong thing sent
Virus info request (PC)
Archive service at Heriot-Watt
Re: Virus in Text Files
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 VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
LEHIIBM1.BITNET for 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: krvw@CERT.SEI.CMU.EDU.
Ken van Wyk
---------------------------------------------------------------------------
Date: Mon, 09 Apr 90 10:30:00 -0400
From: Thank you matchline <S10891KH@SEMASSU.BITNET>
Subject: Gatekeeper 1.1.1 & Scores (Mac)
The following is an excerpt of a letter sent to John Norstadt, Author of
disinfectant and may be of interest to anyone who uses gatekeeper
____________________________________________________________________
SMU, 9-APR-1990
John, I'm sending this to you because I think it may be of interest. I
just downloaded gatekeeper 1.1.1 off the rice archives and was in the
process of evaluating its performance against scores, nVir and WDEF.
Immediately I found a problem. When starting up an application already
infected with scores (on a floppy) gatekeeper announced 3 times that the
virus was attempting to infect the application and its attempt was 'vetoed'
Great so far. However, after that initial warnining I waited about 10
minutes and then checked on the process of the attempted infection. By
that time, pyro had come on and nothing was any different BUT when I
checked the system folder the notepad file and scrapbook files had the
'dogeared page' icon. I ran disinfectant 1.6 and guess what the system was
infected as well as the desktop, clipboard and scrapbook.
It seems that gatekeeper only partly protects from scores attacks. And
worse yet disinfectant had to be run twice to completely remove all bits
and pieces of scores.
- Zav
------------------------------
Date: Mon, 09 Apr 90 12:24:33 -0400
From: jln@acns.nwu.edu
Subject: Disinfectant 1.7 and GateKeeper (Mac)
Disinfectant 1.7 requires GateKeeper privileges even when just scanning.
Earlier versions only required privileges when repairing. I wasn't aware of
this until after I had released 1.7, or I would have mentioned it in the
document.
The solution to this problem is to simply grant Disinfectant all six
GateKeeper privileges.
John Norstad
Academic Computing and Network Services
Northwestern University
------------------------------
Date: 09 Apr 90 13:45:20 +0000
From: rwallace@vax1.tcd.ie
Subject: Re: Universal Virus Detector
jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes:
> I am working with a colleague on defining a robust virus detection
> utility. The following is an extended abstract of a paper which
> discusses an approach we are investigating. The work was undertaken as
> part of a research project sponsored by the National Aeronautics &
> Space Administration at the Johnson Space Center. Please look it over
> and tell us (or Virus-L) what you think.
This is I think the fourth serious attempt on this newsgroup to propose a
universal virus detector. Unfortunately like all the rest it won't work.
(theoretical UVD discussion)
> So to put our theoretical UVD into practice, on, for example, an IBM
> PC, we would do the following:
>
> a. Begin by validating the integrity of the detector code. This has
> been discussed above. [not included in abstract]
How? I haven't copied your entire posting in this followup because it was too
long but I couldn't see any proposed method for validating the detector code.
And an obvious way to defeat your mechanism is to overwrite the detector
program with code that always says "OK".
...
> f. In order to prevent a virus from attacking the CRC table, we will
> add a set of dynamic "State Vectors" for the machine, which define
> the run time environment for the detector. This creates an
> unforgeable "fingerprint" of the detector as it exists in memory
> and can be prepended to each file prior to computing the CRC.
What do you mean? Another obvious way to defeat the detector is to recalculate
CRCs for infected programs and put the new CRC value into the table. I don't
see any way to prevent this other than storing the table offline (which would
create what most users would consider unacceptable hassle).
Also your detector would detect most resident programs as well as multiuser
systems and upgraded versions of the operating system as viruses because it
checks the system call vectors.
"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie
------------------------------
Date: Mon, 09 Apr 90 15:13:00 -1100
From: <RMAP222@euclid.ucl.ac.uk>
Subject: Validate program corrupted?? (PC)
I just received this message. It was posted on the RED-UG list as you can
see. If you have any questions about the message please send them to the
author of the original message.
Nino
*******************************************************************************
*JANET: n.margetic@uk.ac.ucl.euclid | Nino Margetic *
*EARN/BITNET: n.margetic%euclid.ucl.ac.uk@UKACRL | University College *
*INTERNET: n.margetic%euclid.ucl.ac.uk@cunyvm.cuny.edu| Dept. of Med. Physics *
*UUCP: n.margetic%euclid.ucl.ac.uk@ukc.uucp | 11-20 Capper Street *
*Phone: [+44 - 1 | 01 ] 380-9846 | London WC1E 6AJ *
*FAX: [+44 - 1 | 01 ] 380-9577 | Great Britain *
*******************************************************************************
- --------------- Original message follows -------------------------------
Via: UK.AC.RUTHERFORD.MAIL ; Mon, 9 Apr 90 14:51 GMT
(V41 at UK.AC.UCL.EUCLID)
Received:from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 7403; Mon, 09
Apr 90 14:50:10 BS
Received:by UKACRL (Mailer X1.25) id 7680; Mon, 09 Apr 90 14:49:57 BST
Date: Mon, 9 Apr 90 15:17
Reply-To:Gunnar Radons <S46@EARN.DHDURZ1>
Sender: Red File Server Users Group <RED-UG@EARN.DB0FUB11>
From: Gunnar Radons <S46@EARN.DHDURZ1>
Subject: virus alert
To: BSMTP <RMAP222@UK.AC.UCL.EUCLID>
Hello netlanders,
Another topic on viruses. The german computer-journal "DOS-Shareware"
reported the following in it's No. 3 issue :
There is an infected version of SCANV58.zip. Actually the VALIIDATE
program seems to be changed. The original VALIDATE should be a .COM
file, while the corrupt is a .EXE with 46167 bytes (instead of 6485)
The original SCAN.EXE should have the values: Size: 42977 bytes,
Date: 2-15-1990, File Authentication: Check Method 1: 2F16, Method 2:
1C57.
This message is to be found on page 77 of the above journal.
Also there are to files "NORTSTOP.ZIP" and "NORTSHOT.ZIP" which
claim to be written by peter norton. Both contain a trojan which
erases some files between christmas and new year. To identify those
look in the .ZIP file for NORTSHOT.EXE and in the .EXE for the string
"Norton Public". If you find those trojan please inform Tony McNamara
from Norton computing (phone: US: 213/319-2076). The length of NORTSHOT
is 38907 bytes and it's date is 02.01.89 (European format I suppose).
This message is from page s6 of the above journal.
This message will be sent to RED-UG and games-l (Apr. 8. 1990).
Bye,
Gunnar
:----------------------------------------------------------------------:
: :: :
: Gunnar Radons :: Gunnar Radons :
: Astronomisches Recheninstitut Heidelberg :: s46@dhdurz1 :
: Moenchhofstr. 12-14 :: :
: D-6900 Heidelberg :: (+49) 6221 405147 :
: :: :
:------------------------------------------::--------------------------:
: Do you have the solution or are you the problem? :
:----------------------------------------------------------------------:
------------------------------
Date: Mon, 09 Apr 90 15:59:02 -0000
From: LBA002@PRIME-A.TEES-POLY.AC.UK
Subject: Low Level Format (PC)
Many thanks to all those who sent me messages about low-level formatting. I now
have a very clear idea of what it does and when to use it.
Great help (as usual) from the -LIST
Rgds,
Iain Noble
Teesside Polytechnic Library (UK)
- -----------------------------------------------------------------------------
Iain Noble |
LBA002@pa.tp.ac.uk | Post: Main Site Library,
JANET: LBA002@uk.ac.tp.pa | Teesside Polytechnic,
EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL | Middlesbrough,
INTERNET: LBA002%pa.tp.ac.uk@cunyvm.cuny.edu | Cleveland, UK, TS1 3BA
UUCP: LBA002%tp-pa.ac.uk@ukc.uucp | Phone: +44 642 218121 x 4371
- -----------------------------------------------------------------------------
------------------------------
Date: Mon, 09 Apr 90 09:52:07 -1000
From: Jim Wright <jwright@cfht.cfht.hawaii.edu>
Subject: Re: Validating Virus Software
I am willing to start a new mothly posting, which includes validation
information for various popular anti-viral software packages. It need
not be limited to ibmpc software. Each author is free to choose their
own favorite validation method. Due to the nature of this, I will
only accept information from the author, or from an authorized
individual. (Authorized by sending me a post card.)
I will not be able to keep up with this on my own. Out here, ftp and
modems are a bit expensive. So I will rely on the authors to keep
this up to date.
Anyone interested, just drop me a line.
Jim
------------------------------
Date: 09 Apr 90 19:20:10 +0000
From: werner@cs.utexas.edu (Werner Uhrig)
Subject: Re: FTP from SIMTEL20 to VM/CMS (Internet)
> In spite of several months of trying, I have still never successfully
> obtained Disinfectant over the Internet. I believe the problem
> has something to do with 7 databit vs. 8 databit binary
as was already exlained by the moderator, there is indeed a differenc
\ce
when trying to retrieve a binary file from SIMTEL20.
given that folks tend to have other (local) problems downloading
binaries also, I make both binaries *AND* hexed (7-bit ASCII) version
\cs
of all the latest Macintosh anti-virals available for ANON-FTP on
RASCAL.ICS.UTEXAS.EDU in directory "mac/virus-tools"
------------------------------
Date: Mon, 09 Apr 90 16:14:49 -0600
From: David Perales <DPERALES@TRINITY.BITNET>
Subject: What do I buy? (PC)
We are in the market for a good solid product for dealing with the
virus situation in the IBM world. Hopefully something that will give
us a good basis for cures, detection and possibly prevention - a good
all-in-one package. Any suggestions?
Thanx,
David
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
David Perales, M.B.A., C.S.P. BitNet: DPERALES@TRINITY
Micro Programmer Analyst telephony :(512)736-7401
Trinity University Computing Center
715 Stadium Drive, Box 50
San Antonio, Texas 78212
------------------------------
Date: 09 Apr 90 00:00:00 -0500
From: "David.M..Chess" <CHESS@YKTVMV.BITNET>
Subject: re: Universal Virus Detector
jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes:
> If you have questions, or see a flaw in the process, please let us
> know. We are building a virus detector, which could be placed into the
> public domain, that uses the techniques below to detect virus
> infections. Our initial tests have shown encouraging results. ...
These comments are based on the abstract only, not the paper
(I'll eventually figure out how to FTP from here...).
Modification detectors seem like a promising way of detecting at
least some "new" (not seen before) viruses. The usual problems
faced by a modification detector include:
1) A virus that knows about the detector (or about a class
of them to which it belongs) might make changes that the
detector won't detect.
2) A similarly detector-aware virus might update the detector's
database to reflect the changes it makes when it infects.
3) A virus might (by luck or design) modify files in such a way
that the user, presented with a list of files that have
changed, will not notice anything wrong.
4) If the virus is active in the system when the detector runs,
it could lie to the detector about the state of the system.
A simple CRC approach runs into point (1): if lots of people start
using your detector, and it always uses the same CRC polynomial,
it's not all that hard for the virus to include code that patches
infected objects so that the CRC is the same as it was before
infection; a CRC isn't hard to invert. My favorite solution to
this is to allow the user to specify his own polynomial (through
the use of a "key phrase" or whatever); other solutions also
exist (crypto-based MDC's and such). I gather from the abstract
that the exact scheme used isn't fixed by the proposal; that's
a reasonable approach.
I gather that your point (f)
> f. In order to prevent a virus from attacking the CRC table, we will
> add a set of dynamic "State Vectors" for the machine, which define
> the run time environment for the detector. This creates an
> unforgeable "fingerprint" of the detector as it exists in memory
> and can be prepended to each file prior to computing the CRC.
is supposed to deal with my point (2), but I don't really
understand it. If it's possible for the detector to update the
database (and it must be, when the user gets new pieces of
software and so on), then it's possible for a virus to as well,
if the database is ever r/w to the system while the virus is
active.
(3) is one of the harder problems, I think; in some of the
environments that are most important to protect (program
development environments, for instance), many executables
will be expected to change. Helping the user figure out
which changes are OK and which are not is something that
needs considerable thinking about, I think. Doing it
perfectly is probably impossible (a good reason to avoid
calling anything a "universal" virus detector...).
Most of the abstract seems to be devoted to (4); making sure
the virus isn't lurking anywhere when the detector runs.
This is the general computer-security problem of getting the
system into a trusted state; I tend to think that the
problem needs to be solved at the system level rather than
the application level (that is, there should be a good
wired-in procedure for getting the system into a trusted state,
rather than making every security application program do
it itself). I doubt that any piece of software in DOS can
really determine that the system is trustworthy; checking
interrupt vectors doesn't tell you anything about the code
they're pointing to, for instance. Painful as it is, the
only method I know of that I trust is booting cold from a
trusted floppydisk.
Sounds like an interesting project, though, and I -will- try
to get the full paper...
DC
------------------------------
Date: Mon, 09 Apr 90 18:09:12 -0400
From: Joe McMahon <XRJDM@SCFVM.BITNET>
Subject: FTP and .hqx (Mac)
Since I run through vast amounts of sw on various servers about the net,
and it always seems to work for me, try this:
1) ftp to whereever.
2) GET the file. No binary, no translate, zilch.
3) Transfer it up with Kermit.
My feeling is that you may be trashing the file by insisting on
transferring it as binary when it isn't. HQX format (as is used on the
FTP servers I know of) is ASCII only, designed not to get trashed by
character translations (e.g., EBCDIC to ASCII). Try not doing anything
but the transfer, and I think you'll find this will work.
--- Joe M.
------------------------------
Date: 10 Apr 90 00:19:57 +0000
From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal)
Subject: Re: Virus in Text Files (Mac)
Macintosh datafiles, as I understand them, have 2 parts, a resource
fork and a data fork. Anything in resource fork (so I've been told)
can execute. Does this imply that one could bury a virus in the
resource fork of a data file?
I'm sure that this has been hashed over before.
Cheers
Woody
------------------------------
Date: 10 Apr 90 01:35:25 +0000
From: rwillis@hubcap.clemson.edu (Richard "Crash" Willis)
Subject: Oops- wrong thing sent
OOPS! Sorry guys, I sent the wrong file to a few people. Please ask
again and I'll send the right information. BTW- the paper itself is not
yet avalible (although that wil change in a few days) however, the
infomation I do have avalable consist of a description of Internet,
Virus De-infection, a theory on a new type of virus prevention and
several other papers. Sorry again for the mess up.
>* Sigh *< I'd better dig out my flame-proof underware for a few days
- -Richard rwillis@hubcap.clemson.edu
"No matter how subtle the wizard, a dagger between the shoulderblades
seriously cramps his style"
-Stephen Burst
------------------------------
Date: 10 Apr 90 01:58:32 +0000
From: malv_ss@uhura.cc.rochester.edu (Max Avarez)
Subject: Virus info request (PC)
Does anyone know of a virus that changes the size of PC files
(usually .exe files) to 2048K?
Also, what is the best virus detection program for the PC?
Thanks,
Max Alvarez (malv_ss@uhura.cc.rochester.edu)
University of Rochester
------------------------------
Date: Tue, 10 Apr 90 10:29:19 -0000
From: David.J.Ferbrache <davidf@CS.HW.AC.UK>
Subject: Archive service at Heriot-Watt
Just a quick note to apologise for disruption to the archive service at
Heriot-Watt over the last month. The network core is due to change to a
Sun system from an ageing Vax, in the meantime a re-organisation of archive
service will take place.
Normal service for immediate processing of email will be restored by end May.
The archive contents will be extended to include the following:
1. General document archives (viruses)
2. PC, Mac, Amiga, Atari and Apple 2 anti-viral software
3. Archives of CERT, DDN SC and other advisories
4. Patches for BSD Unix releases
5. Risks digest backissues
6. Virus-l digest backissues
In addition I am considering a protocol for access to more sensitive materials
including backissues of the Zardoz security digest, Phage mailing list
(historical material from the Internet worm period), and other lists.
These will probably be available by restricted NIFTP.
Again apologies for the disruption.
- -----------------------------------------------------------------------------
\c-
Dave Ferbrache Internet <davidf@cs.hw.ac.uk>
Dept of computer science Janet <davidf@uk.ac.hw.cs>
Heriot-Watt University UUCP ..!mcvax!hwcs!davidf
79 Grassmarket Telephone +44 31-225-6465 ext 553
Edinburgh, United Kingdom Facsimile +44 31-220-4277
EH1 2HJ BIX/CIX dferbrache
- -----------------------------------------------------------------------------
\c-
------------------------------
Date: Tue, 10 Apr 90 09:27:29 -0400
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Virus in Text Files
cdss!culliton@uunet.UU.NET (Tom Culliton) writes:
>How many times has this question been answered? If you can't execute the file
>or run it via an interpreter it can't carry a virus.
A counterexample to this assertion is the wdef viruses on the macs. They are
carried in the Desktop file which is a data file describing the layout of the
windows.
>If it's source code for a compiler or interpreter the danger is present that
>it contains malicious instructions but visual inspection can quickly settle
>that.
You're saying that you can quickly read the source code to an entire compiler
and understand everything it does? I find this extremely hard to believe.
ajr
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253