From lehigh.edu!virus-l Fri Mar 26 03:34:31 1993 remote from vhc
Received: by vhc.se (1.65/waf)
via UUCP; Fri, 26 Mar 93 21:43:51 GMT
for mikael
Received: from fidoii.CC.Lehigh.EDU by mail.swip.net (5.65c8-/1.2)
id AA19640; Fri, 26 Mar 1993 15:51:26 +0100
Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA28019
(5.67a/IDA-1.5 for <
[email protected]>); Fri, 26 Mar 1993 08:34:31 -0500
Date: Fri, 26 Mar 1993 08:34:31 -0500
Message-Id: <
[email protected]>
Comment: Virus Discussion List
Originator:
[email protected]
Errors-To:
[email protected]
Reply-To: <
[email protected]>
Sender:
[email protected]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <
[email protected]>
To: Multiple recipients of list <
[email protected]>
Subject: VIRUS-L Digest V6 #50
VIRUS-L Digest Friday, 26 Mar 1993 Volume 6 : Issue 50
Today's Topics:
Integrity checking (was: scanners)
Re: Cross-platform viruses ?
Re: Scanners getting bigger and slower
Best Net Antivirus (Novell)
scanners for os/2 (OS/2)
Re: Int 21 fn 4bh (PC)
Re: March 1992 and the media (PC)
Help. A virus or what? (PC)
Re: partition table (PC)
Re: Michelangelo (PC)
Re: Can I Get Infected If... (PC)
Re: Partition table viruses (PC)
Re: Signitures (PC)
Re: Viruses in South Africa (PC)
Re: Michelangelo (PC)
CLEAN Recovery? (PC)
F-PROT and Novell (PC)
Re: Virus that infects while Scanning? (PC)
Re: Variation of Michaelangelo? (PC)
Re: scanners. (PC)
New Sentencing Guidlines
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. (The complete set of posting guidelines is available by
FTP on cert.org or upon request.) Please sign submissions with your
real name. Send contributions to
[email protected]. Information on
accessing anti-virus, documentation, and back-issue archives is
distributed periodically on the list. A FAQ (Frequently Asked
Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5). Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<
[email protected]>.
Ken van Wyk,
[email protected]
----------------------------------------------------------------------
Date: Wed, 24 Mar 93 09:14:13 -0500
From: Y. Radai <
[email protected]>
Subject: Integrity checking (was: scanners)
Inbar Raz writes:
> Malte Eppert writes:
>>> Making CRC checks from a BOOTING FLOPPY will also catch ANY
>>> virus, provided it hasn't infected your floppy yet.
>>
>> Sorry, it won't. It will catch any modification, that's true. But if you
>> get infected with a slow virus, the user just would regard the change as
>> legitimate. Then, Vesselin introduced the idea of a DOS file
>> fragmentation attack. You could not detect that with a file-oriented CRC
>> checker, too.
>
> Look. In order for a file to infect a virus it must either add itself to the
> file, or overwrite or replace the first file's cluster (known methods of
> infection, correct me if I'm missing anything).
You certainly are missing things, for example companion viruses and
"fragmentation" viruses.
> If you run a CRC check DAILY,
> you WILL locate these changing. What you're saying is true only if I had let
> my system get infected, and only THEN, after the viruses had already started
> to activate, I ran the tests.
No, it's also true in the case of the above two types of viruses. In
these cases, a naive integrity checker (and unfortunately that's the
great majority) will *not* detect any change.
In effect, it's also true in the case of the so-called "slow"
viruses (that's Vesselin's term; I call them "ambiguity" viruses).
You're right that the checker will report a change, but in all proba-
bility the user will think that the change is due to a deliberate
action on his part instead of to a virus, in which case the integrity
checking has not succeeded in its goal. (However, as I mentioned in
a previous posting, there are some measures that can be taken to
detect such viruses, even though they're not part of integrity
checking as such.)
If you're not familiar with the concepts of companion viruses and
slow viruses, I suggest you take a look at questions B8 and B6 of the
FAQ sheet before you reply.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
P.S. Inbar, just as you correctly pointed out to someone that he
should mention the person to whom he is replying, I think you should
pay attention to the Subject line. This discussion long ago ceased to
be about "scanners".
------------------------------
Date: Wed, 24 Mar 93 19:30:53 +0000
From:
[email protected] (Chris Antkow)
Subject: Re: Cross-platform viruses ?
[email protected] (Denis Brown) writes:
>running on the same thin-ethernet backbone. Are there any known viruses
>which can propagate across platforms such as these ? I assume that it
At present, I do not believe that there are any viruses which can
propagate cross platform from an IBM to a MAC or vice versa. It would be
too huge of a virus and would probably be easily detected on a PC (At
least...)
Comming from a programmer (>sic<) it would be a very LARGE endeavour to
code a cross-platform virus...
Cheers...
Chris
[email protected]
------------------------------
Date: 25 Mar 93 10:32:22 +0000
From:
[email protected] (Fridrik Skulason)
Subject: Re: Scanners getting bigger and slower
[email protected] (Inbar Raz) writes:
>The whole point of having more than one scanner, is that there is a
>considerable amount of viruses which are considered rare, or extinct, whose
>chances of infecting you are unreal.
Unreal ? Well, the problem is that almost all "extinct" or "research only"
viruses are generally available on the virus exchange BBSes - so somebody
could download one of them and spread it.
In my opinion, there is nothing to be gained by scanning just for a subset
of the viruses - no significant speed increase, only a little less memory
required.
>I was predicting a future situation. Perhaps today not, but in the future, if
>viruses keep multiplying like they do, soon enough all anti-viruses will have
>to be written for protected mode, otherwise there wouldn't be enough memory
>for all virus information, or speed :-)
As I have said before - the number of viruses should not affect the speed
significantly - memory shortage is a problem, however - in 5 years a virus
scanner might require more than 640K of memory to run....but so what ?
I think it is reasonable to expect "everybody" to have more memory than that
in 5 years..
- -frisk
- --
Fridrik Skulason Frisk Software International phone: +354-1-694749
Author of F-PROT E-mail:
[email protected] fax: +354-1-28801
------------------------------
Date: Wed, 24 Mar 93 15:57:15 +0000
From:
[email protected] (Keren Shmuel)
Subject: Best Net Antivirus (Novell)
Hello there
I am sorry if it is not the right place to ask this Q but i dont know
where else i can post it:
The Q is : what is the best AntiVirus for a net (NOVELL) today ?
If you can please Email me
I know that I can check it out in magazines and such but I would like
YOUR idea too.
Thanks in advance
Shmuel Keren
------------------------------
Date: 24 Mar 93 10:59:44 -0600
From: "
[email protected]"@kinni.acc.uwrf.edu
Subject: scanners for os/2 (OS/2)
is there a *good* pd/shareware scanner for os/2 using one
high performance and one normal (fat) hard drive ?
- --
*************************************************************************
* * *
* byron patterson * don't ask me, i just work here *
* * *
*
[email protected] * *
* * *
*************************************************************************
------------------------------
Date: Thu, 25 Mar 93 09:53:00 -0500
From: Donald G Peters <
[email protected]>
Subject: Re: Int 21 fn 4bh (PC)
There are legitimate uses for DOS functions like Int 21 Fcn 4B. I disagree
with "IR" who recently said that we should not be discussing the subfunctions
of Int 21 fcn 4B. IR seemed concerned that it might help virus writers.
Well, so does a course on structured programming! :-) I have very legitimate
needs to discuss function 4B, which may even result in utilities that
deter viruses. Isn't it likely that this function is even being used
today by some anti-viral products?
This week I was exploring how to add an envelope around an EXE file in
order to make the EXE file behave differently. Without going into
excessive detail (I haven't figured it all out, either) I was trying
to add "Loading, please wait..." to the start of an EXE. EXE header
formats still confuse me, especially the fact that files can be
bigger than DOS-addressable memory!
------------------------------
Date: Wed, 24 Mar 93 07:12:32 -0500
From: Y. Radai <
[email protected]>
Subject: Re: March 1992 and the media (PC)
Rob Slade writes:
> In the fall of 1989, there was a large amount of media attention
> given to two Jerusalem variants, Datacrime and "Columbus Day".
^^^^^^^^^^^^^^^^^^
What??? Since when is Datacrime a "Jerusalem variant"??? (It's hard
to think of a virus which bears *less* resemblance to the Jerusalem.)
As for "Columbus Day", that was not, to the best of my knowledge, a
variant of any virus, but just an inappropriate alias for the Data-
crime, based on the mistaken belief that the virus performs its damage
on Oct. 12, when in actuality it does it on Oct. 13 (through Dec. 31).
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Wed, 24 Mar 93 15:10:08 +0200
From:
[email protected]
Subject: Help. A virus or what? (PC)
HELP ! Is this an virus or a malfunction of some kind?
- ------------------------------------------------------------------
Tried to use several program-managers in windows.
This lead to: (many) lost clusters in 144 chains. (data, programs etc)
Nothin wrong, yet.
But after some time...
1. The screen was filled with different characters of all colors,
some characters blinking, others not.
This happened: 15.03.1993 22.00-23.00
2. Couldn't do anything.
3. Turned off the power after about 15c secs
Extended error 5
crosslinked files (20 or more?)
16.03.1993 07.00
Trying to execute programs lead to following errormessages:
Cannot execute ...
Load error (170) (?file...)
- -------------------------------------------------------------------------
Virusscan (mcAfee, ver 1.02) -> no viruses found
F-Prot 2.07 secure scan / all files -> no viruses found
F-Prot 2.07 Heuristics/hard disk/report only/boot&file/all files
gives:
This is an invalid executable file. It starts with an
instruction which transfers control out of the program. Any attempt to
run this program will result in a system crash.
(* allmost all files *)
This program contains code to write directly to the disk, bypassing the
file system (INT 13 or INT 26H calls). This does not imly that it is a
virus, but it contains dangerous (and possibly destructive) code.
This program modifies itself in a highly suspicious way. It is either infected
or a badly written program which overwrites code with data.
.contains code to search for other executable files...
(*whereis*)
- -------------------------------------------------------------------------
More programs stopped work after scanning them.
Deleting suspicious files didn't help:
16.03.1993 07:35 suspicious 55 files
->deleted
16.03.1993 08:19 suspicious 10 files
->deleted
Got again a very strange errormessage:
Extended error 78 (or 76 or something)
More problems:
C>rd program
Invalid path, not directory, or directory not empty
dir program
<DIR> 02-20-93 6:42p
<DIR> 02-20-93 6:42p
. ..
&-D@tx& I\ <DIR> 02-24-20 2:38p
/ .. . <-not a line
Fo e V*[F(integral-sign)&- D 673120000 00-00-33 1:16p
. <-not a line
4 file(s) 673120000 bytes
48113664 bytes free
The hard disk is about 120 MB
chkdsk/f didn't help
(bootsector OK, FAT OK)
Format c: did not work
-> Sector not found...
FDISK (delete, create...) solved the problem.
- -------------------------------------------------------------------------------
- -----
I have not yet found a virus, only suspicious files.
What could I do? I can not back up all changed files every day.
Please, answer soon - it is coming back?
- ----------------------------------------------------------------------------
------------------------------
Date: Wed, 24 Mar 93 08:17:56 -0500
From: Garry J Scobie Ext 3360 <
[email protected]>
Subject: Re: partition table (PC)
> Date: Thu, 11 Mar 93 18:53:03 -0500
> From: bill.lambdin%
[email protected] (Bill Lambdin)
> Subject: partition table (PC)
>
> Most boot sector viruses hide in the boot sector of floppies, but on hard
> drives, they hide in the partion table.
I'd go along with that. Most do!
> A fair way to get rid of boot sector viruses without using AV softwarem or
> low level formatting the hard drive, is to boot clean from a DOS 5.0
> bootable diskette, then issue the following command.
>
> FDISK/MBR.
>
This will not work for the boot sector virus FORM which infects the
boot sector of a floppy disk and the boot sector of the hard disk (as
opposed to the master boot record).
Garry Scobie
Edinburgh University Computing Services
Scotland e-mail:
[email protected]
------------------------------
Date: 24 Mar 93 14:58:19 +0000
From:
[email protected] (Fridrik Skulason)
Subject: Re: Michelangelo (PC)
> > in that way? The partition of the drive was wiped away. How do
> > one recover the information on the disk?
>I'm sorry, all one can say is: Forget it, it's impossible :-(((
Not necessarily. It depends on several factors:
How many heads the disk has - the virus only wipes 0-3
How many sectors per track - the virus only wipes the first 17.
For how long the virus was allowed to run...in starts on track 0, and
then moves upward.
If the virus was not allowed to complete its destruction, and if the hard
disk is very bug, it might be possible to recover - I know of one case where
the virus only trashed the MBR, the DOS boot sector, one copy of the FAT and
everything in the /WINDOWS directory .... meaning that it was relatively
easy to recover using standard tools like NDD and FDISK.
- -frisk
- --
Fridrik Skulason Frisk Software International phone: +354-1-694749
Author of F-PROT E-mail:
[email protected] fax: +354-1-28801
------------------------------
Date: Wed, 24 Mar 93 08:15:21 -0800
From: An-Ly Yao <
[email protected]>
Subject: Re: Can I Get Infected If... (PC)
Y o u won't get infected! (Sorry for the weak joke...)
But if your PC used a COMMAND.COM on that disk for the DIR, and if the
COMMAND.COM was infected, than now perhaps also your PC might be infected.
- --Goetz--
------------------------------
Date: 24 Mar 93 15:09:59 +0000
From:
[email protected] (Paul Ducklin)
Subject: Re: Partition table viruses (PC)
Thus spake
[email protected] (Vesselin Bontchev):
>
[email protected] (Sarel Lugtenburg) writes:
>> We had just an outbreak of a virus that infects the partition table.
>> It trigger on any date in March.
. . .
>In general, to remove a MBR infector, all you need to do is to boot
>from an uninfected write-protected DOS 5.0 (the version is important)
>system diskette, and to run the command FDISK/MBR.
. . .
>However, having in mind that you are from South Africa and have a MBR
>infector that triggers on any date in March, I strongly suspect that
>you have a version of the Exe_Bug virus.
Yep, I bet you do, Sarel.
FDISK /MBR won't help much -- it will rewrite the MBR *code*, but won't
recover the partition table, which was overwritten by the virus. Usually,
you could find the old partition table at 0.0.17, and copy it back with
suitable a-v software, or with a disc editor. However, if the virus
triggers, you've got more on your plate than removing the virus [which
is one of the few things left behind apres la deluge :-(]. Wondering
why-oh-why you didn't do that last backup is perhaps one of them...
So, if you've got an MBR infector like Exebug or Bunny, which both ruin
the partition table info in the MBR, then FDISK /MBR will remove the
virus -- but will leave your hard drive unbootable and [after you boot
from A:] will yield drive C: inaccesible to DOS ["Invalid drive spec-
ification"]. In such circumstances, don't panic -- drive C:, D: etc are
all probably there -- DOS just doesn't have the requisite partitioning
information to assign drive letters to those logical drives.
Careful work with a sector editor will probably turn up the old partition
record, from which the partition table can be restored. Or, if you have
one of those "emergency discs" which many utility packages let you make,
you probably have a copy of the partition table stored away. Failing that,
ask someone who knows the layout of a PC hard drive to help you rebuild
the partition table by hand. It's not too difficult...
Paul Ducklin
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ Paul Ducklin
[email protected] /
/ CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
- --
- --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--
Paul Ducklin
[email protected]
CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
------------------------------
Date: 24 Mar 93 15:29:05 +0000
From:
[email protected] (Paul Ducklin)
Subject: Re: Signitures (PC)
>: To check for an executable file a virus will read in the appropriate bytes
>: and check to see if it is "MZ".
>: Why do some viruses check for "ZM"? What kind of file does this denote?
"MZ" denotes an .EXE file [the initials of Mark Zbikowski (sp?), who
devised the file format]. DOS *also* checks for "ZM", so some viruses
do so, too.
Why? I dunno. Just one of those arcane "things" about DOS buried in the
mists of time [and CP/M], I suppose. Or perhaps Mark Z. had a good
friend called, say, Zane Moosa [there is such a person; he's a well-known
South African soccer player] whom he wished to immortalise too :-)
Paul
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ Paul Ducklin
[email protected] /
/ CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
- --
- --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--
Paul Ducklin
[email protected]
CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
------------------------------
Date: 24 Mar 93 16:11:52 +0000
From:
[email protected] (Paul Ducklin)
Subject: Re: Viruses in South Africa (PC)
>Paul,
>We've been getting reports of many virus outbreaks in South Africa
>lately. Could you provide some factors that you believe is
>contributing to this? Are there any particular hotbed locations
>within S. Africa or is it simply the whole of S.Africa?
Sorry, folks, for the delay in responding. Hey, one could write
reams of pseudo-scholarly stuff about virus epidemiology; sociological
phenomena germane to virus production in the developing world;
viruses and the road to a post-apartheid society. How about:
"Liberation Virology: a Study of Counter-Cultural Issues in the
Battle for the Desktop".
Seriously, though, SA does have a noticeable virus problem. I've looked
at it before, and attempted some analysis [if you're interested in a
written account, try the proceedings of the EICAR Conference of December
1992 -- there's a paper in there called "What did we learn from March
6th, or Why are users still asking the same old questions?" <yes, I
know, and I apologise for the pompo-lengthy title; it seemed perfectly
reasonable at the time, somehow>].
However, my own reading of the reason for lots of reports from SA in the
news *lately* is the unfortunate [or perhaps quite deliberate...] coincidence
of trigger dates between Michelangelo and Exebug.C [a peculiarly South
African problem, seemingly written here]. Ergo, *double* hypeability for
the media -- sensation, in a word. Rehashing last year's old Michelangelo
stories might have been stretching things; reiterating old stories with
new, new *bad* news [Exebug.C trashes drives throughout March...] makes
good copy. And so -- lots of news stories round the world with the words
"computer virus" and "South Africa" in the same sentence.
I'm not saying that hype explains away SA's virus problem. But it certainly
helps create a curious picture of it -- and leads to all sorts of zany
speculation about its causes.
Paul
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ Paul Ducklin
[email protected] /
/ CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
- --
- --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--
Paul Ducklin
[email protected]
CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
------------------------------
Date: 24 Mar 93 15:24:05 +0000
From:
[email protected] (Paul Ducklin)
Subject: Re: Michelangelo (PC)
> > A friend of mine couldn't boot his computer today (6:th of
> > March). Could it be the Michelangelo Virus?
>Yep :-(.
> > in that way? The partition of the drive was wiped away. How do
> > one recover the information on the disk?
>I'm sorry, all one can say is: Forget it, it's impossible :-(((
Well, not every Michelangelo story has a sad ending. I did a data
recovery a week or two ago for a guy who'd been hit -- he had a 200MB
drive, and as M takes only a 9MB "bite" out of the drive, what was left
turned out to be pretty useful. We actually got back nearly all of
what he wanted. Last year, too, we did a number of successful recoveries
for panicked people. Of course, we did a lot of "cry on my shoulder,
then forget it, it's impossible", too!
But this 200MB guy's hit makes an amusing story: he rarely, if ever,
switches off his PC. On Saturday March 6th, however, someone in his
office decided they wanted to switch off his desk lamp, and did so
at the socket outlet. It was one of those double-outlets with the
sockets at a curious angle [modern-artish?], for which it is impossible
to determine merely by observation which switch belongs to which socket.
Yeah, they chose the wrong switch; then "Oops, sorry", and switched back
on again. "Funny, this machine won't boot".
And we had a guy last year [one of the successful recoveries -- this chap
had source code he wanted back written in <wait for it> PL/1 <wow>] who
rolled in on Feb 6th. His clock was wrong -- and all his colleagues thought
it was great, as they got a month's warning :-)
Paul Ducklin
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ Paul Ducklin
[email protected] /
/ CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
- --
- --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--
Paul Ducklin
[email protected]
CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
------------------------------
Date: Wed, 24 Mar 93 19:37:11 +0000
From:
[email protected] (Chris Antkow)
Subject: CLEAN Recovery? (PC)
Recently, an aquaintance of mine was infected by the Stoned virus and
proceeded to clean it will CLEAN v1.02...
Their system was an old 8086 with a 30mb HD running DOS v3.1 (Yeah!
OLD!). Stoned was nestled in the partition table... CLEAN did a great
job getting rid of Stoned in the partition table, but it also did a
great job of getting rid of the partition table...
Whenever they tried to access drive C: after that, the system would
respond with "Drive not ready" or something to that effect whenever they
tried to do a directory or otherwise access any information on C:
My question is, is there any way of rebuilding a "CLEANed" partition
table??? Wouldn't this be considered a rather LARGE bug on the part of
CLEAN?
Any feedback ASAP would be greatly appreciated...
Cheers...
Chris
[email protected]
PS: I'm really embarassed about asking about this seeing as how I've
only started reading Internet conferences for the last 4 months, but
what does IMHO stand for... (Geez don't I feel small...)
------------------------------
Date: Wed, 24 Mar 93 20:36:02 -0500
From:
[email protected]
Subject: F-PROT and Novell (PC)
Until recently I have been using F-Prot's VIRSTOP on every networked
station, loading into memory thorugh the autoexec.bat file. However I have
just discovered that if I want to unload Novell's network drivers from
memory, I first must unload anything that was loaded after, such as
VIRSTOP. I did not see anything in the documentation (Install.doc and
virstop.doc) which indicates that virstop can be removed from memory. Does
anyone have any solution?
TIA
[email protected]
------------------------------
Date: Thu, 25 Mar 93 05:54:52 -0500
From: Otto Stolz <
[email protected]>
Subject: Re: Virus that infects while Scanning? (PC)
On Fri, 12 Mar 93 23:38:53 +0000 Ryan Kolter <
[email protected]> said:
> [...] His claim was that it dodged the scan by taking itself
> out of memory during the memory check (McAffee) and then reloaded into
> memory and removed itself from the infected file during the scan of
> that file.
Or, perhaps, that the scanner used does not know of it, and hence does
not recognize it in memory. Which version of SCAN did Ryan's friend use?
Did he try several different, up-to-date scanners, like Frisk's F-PROT
or Alan's FINDVIRU?
> After that, it would infect every .exe that was scanned.
> Thus the process of scanning actually infected the whole drive.
There are several viruses that infect on mere viewing (e.g. scanning)
program files; they are known as "fast infectors". Most of them infect
both COM and EXE files.
If I am not mistaken, the Jerusalem.Mummy family of fast infectors
infects only EXE files. However, SCAN 99 recognizes them as follows
(thanks to Vesselin for his list):
Standard CARO name SCAN report
Jerusalem.Mummy.1_0 FamE [FE]
Jerusalem.Mummy.1_2 Mummy [Mum], FamE [FE]
Jerusalem.Mummy.2_1.A Mummy [1339]
Jerusalem.Mummy.2_1.B Mummy [1339]
I've tried, unsuccesfully, to send a description of Mummy to Ryan Kolter
but apparently the address he gave in his poster is not valid. To avoid
similar disasters, I rather give two addresses :-)
Best wishes,
Otto Stolz <
[email protected]>
<
[email protected]>
------------------------------
Date: Thu, 25 Mar 93 06:16:20 -0500
From: Otto Stolz <
[email protected]>
Subject: Re: Variation of Michaelangelo? (PC)
On Tue, 16 Mar 93 20:59 +0000 Gary Brown <
[email protected]> said:
> Last year I detected and cleaned MichaelAngelo [...] This year
> I scanned with the same version about mid-Feb and I was clean.
> The only software I bought since then [...] was clean. [...]
>
> my question is: Does anyone know of a modified MichaelAngelo that is
> not detectable by software that could detect it last year??
Dear Gary,
Did you scan your data diskettes? All of them? Really all of them? Even
those you forgot in obscure hiding places, or used as bookmarks or as
saucers :-) ? All of the diskettes your friends brought in?
Dear all,
the most probable reason for Gary's experiences is a Michelangelo-
infected floppy disk he as inadvertently booted from.
This common source of re-infection renders clean-up after virus
infection so expensive, and so error-prone: you have to catch *all*
instances on *all* media, including HDs of *all* computers that were in
touch with any infected disk, and including *all* disks that were in
touch with any infected computer{, and ..., and ..., and...}... .
Good luck,
Otto Stolz <
[email protected]>
<
[email protected]>
------------------------------
Date: 25 Mar 93 14:53:20 +0000
From:
[email protected] (Fridrik Skulason)
Subject: Re: scanners. (PC)
[email protected] (Inbar Raz) writes:
> > ...or the program does some self-testing
> > ...or the program contains internal overlays
>These are exceptions. Same exceptions as for PKLite.
Exceptions maybe - but nevertheless a whole lot of them....more and more
programs are distributed with some self-testing built in.
>Anyway, if it's a boot infector, than it won't infect your Hd, will it?
No, but it will be active when you boof from a diskette, and will spread
quite happily without being detected by an integrity checker. I'm not
saying a virus like tis will spread well, but they exist.
>If it's slow, it doesn't matter. 'Slow' relates to it's damaging mechanism,
>meaning it takes time to notice the virus's damage,
Huh ? No..."slow" means that it only infects when some other program
(such as a compiler) modifies an executable.
- -frisk
- --
Fridrik Skulason Frisk Software International phone: +354-1-694749
Author of F-PROT E-mail:
[email protected] fax: +354-1-28801
------------------------------
Date: Wed, 24 Mar 93 20:33:47 +0000
From: "George Guillory" <
[email protected]>
Subject: New Sentencing Guidlines (long)
The United States Sentencing Commission has published for public
comment a proposed new sentencing guideline that would apply when
an individual is convicted of violating The Computer Fraud and
Abuse Act of 1986 (18 U.S.C. 1030). Unlike the current applicable
guideline (U.S.S.G. 2F1.1) which relies heavily on financial loss
in determining the appropriate sentence in a computer crime case,
the new proposed guideline (U.S.S.G. 2F2.1) focuses on data con-
fidentiality and integrity and the harm that occurs when confidentiality
or integrity are violated.
UNITED STATES SENTENCING COMMISSION
AGENCY: United States Sentencing Commission.
57 FR 62832
December 31, 1992
Sentencing Guidelines for United States Courts
ACTION: Notice of proposed amendments to sentencing guidelines,
policy statements, and commentary. Request for public comment.
Notice of hearing.
SUMMARY: The Commission is considering promulgating certain
amendments to the sentencing guidelines, policy statements, and
commentary. The proposed amendments and a synopsis of issues to be
addressed are set forth below. The Commission may report amendments
to the Congress on or before May 1, 1993. Comment is sought on all
proposals, alternative proposals, and any other aspect of the
sentencing guidelines, policy statements, and commentary.
DATES: The Commission has scheduled a public hearing on these
proposed amendments for March 22, 1993, at 9:30 a.m. at the
Ceremonial Courtroom, United States Courthouse, 3d and Constitution
Avenue, NW., Washington, DC 20001.
Anyone wishing to testify at this public hearing should notify
Michael Courlander, Public Information Specialist, at (202) 273-4590
by March 1, 1993.
Public comment, as well as written testimony for the hearing,
should be received by the Commission no later than March 15, 1993,
in order to be considered by the Commission in the promulgation of
amendments due to the Congress by May 1, 1993.
ADDRESSES: Public comment should be sent to: United States
Sentencing Commission, One Columbus Circle, NE., suite 2-500, South
Lobby, Washington, DC 20002-8002, Attention: Public Information.
FOR FURTHER INFORMATION CONTACT: Michael Courlander, Public
Information Specialist, Telephone: (202) 273-4590.
* * *
59. Synopsis of Amendment: This amendment creates a new guideline
applicable to violations of the Computer Fraud and Abuse Act of 1988 (18
U.S.C. 1030). Violations of this statute are currently subject to the fraud
guidelines at S. 2F1.1, which rely heavily on the dollar amount of loss caused
to the victim. Computer offenses, however, commonly protect against harms that
cannot be adequately quantified by examining dollar losses. Illegal access to
consumer credit reports, for example, which may have little monetary value,
nevertheless can represent a serious intrusion into privacy interests. Illegal
intrusions in the computers which control telephone systems may disrupt normal
telephone service and present hazards to emergency systems, neither of which
are readily quantifiable. This amendment proposes a new Section 2F2.1, which
provides sentencing guidelines particularly designed for this unique and
rapidly developing area of the law.
Proposed Amendment: Part F is amended by inserting the following section,
numbered S. 2F2.1, and captioned "Computer Fraud and Abuse," immediately
following Section 2F1.2:
"S. 2F2.1. Computer Fraud and Abuse
(a) Base Offense Level: 6
(b) Specific Offense Characteristics
(1) Reliability of data. If the defendant altered information, increase by
2 levels; if the defendant altered protected information, or public records
filed or maintained under law or regulation, increase by 6 levels.
(2) Confidentiality of data. If the defendant obtained protected
information, increase by 2 levels; if the defendant disclosed protected
information to any person, increase by 4 levels; if the defendant disclosed
protected information to the public by means of a general distribution system,
increase by 6 levels.
Provided that the cumulative adjustments from (1) and (2), shall
not exceed 8.
(3) If the offense caused or was likely to cause
(A) interference with the administration of justice (civil or criminal) or
harm to any person's health or safety, or
(B) interference with any facility (public or private) or communications
network that serves the public health or safety, increase by 6 levels.
(4) If the offense caused economic loss, increase the offense level
according to the tables in S. 2F1.1 (Fraud and Deceit). In using those
tables, include the following:
(A) Costs of system recovery, and
(B) Consequential losses from trafficking in passwords.
(5) If an offense was committed for the purpose of malicious destruction or
damage, increase by 4 levels.
(c) Cross References
(1) If the offense is also covered by another offense guideline section,
apply that offense guideline section if the resulting level is greater. Other
guidelines that may cover the same conduct include, for example: for 18 U.S.C.
1030(a)(1), S. 2M3.2 (Gathering National Defense Information); for 18 U.S.C.
1030(a)(3), S. 2B1.1 (Larceny, Embezzlement, and Other Forms of Theft), S.
2B1.2 (Receiving, Transporting, Transferring, Transmitting, or Possessing
Stolen Property), and S. 2H3.1 (Interception of Communications or
Eavesdropping); for 18 U.S.C. 1030(a)(4), S. 2F1.1 (Fraud and Deceit), and S.
2B1.1 (Larceny, Embezzlement, and Other Forms of Theft); for 18 U.S.C. S.
1030(a)(5), S. 2H2.1 (Obstructing an Election or Registration), S. 2J1.2
(Obstruction of Justice), and S. 2B3.2 (Extortion); and for 18 U.S.C. S.
1030(a)(6), S. 2F1.1 (Fraud and Deceit) and S. 2B1.1 (Larceny, Embezzlement,
and Other Forms of Theft).
Commentary
Statutory Provisions: 18 U.S.C. 1030(a)(1)-(a)(6)
Application Notes:
1. This guideline is necessary because computer offenses often harm
intangible values, such as privacy rights or the unimpaired operation of
networks, more than the kinds of property values which the general fraud table
measures. See S. 2F1.1, Note 10. If the defendant was previously convicted of
similar misconduct that is not adequately reflected in the criminal history
score, an upward departure may be warranted.
2. The harms expressed in paragraph (b)(1) pertain to the reliability and
integrity of data; those in (b)(2) concern the confidentiality and privacy of
data. Although some crimes will cause both harms, it is possible to cause
either one alone. Clearly a defendant can obtain or distribute protected
information without altering it. And by launching a virus, a defendant may
alter or destroy data without ever obtaining it. For this reason, the harms
are listed separately and are meant to be cumulative.
3. The terms "information," "records," and "data" are interchangeable.
4. The term "protected information" means private information, non-public
government information, or proprietary commercial information.
5. The term "private information" means confidential information (including
medical, financial, educational, employment, legal, and tax information)
maintained under law, regulation, or other duty (whether held by public
agencies or privately) regarding the history or status of any person,
business, corporation, or other organization.
6. The term "non-public government information" means unclassified
information which was maintained by any government agency, contractor or
agent; which had not been released to the public; and which was related to
military operations or readiness, foreign relations or intelligence, or law
enforcement investigations or operations.
7. The term "proprietary commercial information" means non-public business
information, including information which is sensitive, confidential,
restricted, trade secret, or otherwise not meant for public distribution. If
the proprietary information has an ascertainable value, apply paragraph (b)
(4) to the economic loss rather than (b) (1) and (2), if the resulting offense
level is greater.
8. Public records protected under paragraph (b) (1) must be filed or
maintained under a law or regulation of the federal government, a state or
territory, or any of their political subdivisions.
9. The term "altered" covers all changes to data, whether the defendant
added, deleted, amended, or destroyed any or all of it.
10. A "general distribution system" includes electronic bulletin board and
voice mail systems, newsletters and other publications, and any other form of
group dissemination, by any means.
11. The term "malicious destruction or damage" includes injury to business
and personal reputations.
12. Costs of system recovery: Include the costs accrued by the victim in
identifying and tracking the defendant, ascertaining the damage, and restoring
the system or data to its original condition. In computing these costs,
include material and personnel costs, as well as losses incurred from
interruptions of service. If several people obtained unauthorized access to
any system during the same period, each defendant is responsible for the full
amount of recovery or repair loss, minus any costs which are clearly
attributable only to acts of other individuals.
13. Consequential losses from trafficking in passwords: A defendant who
trafficked in passwords by using or maintaining a general distribution system
is responsible for all economic losses that resulted from the use of the
password after the date of his or her first general distribution, minus any
specific amounts which are clearly attributable only to acts of other
individuals. The term "passwords" includes any form of personalized access
identification, such as user codes or names.
14. If the defendant's acts harmed public interests not adequately
reflected in these guidelines, an upward departure may be warranted. Examples
include interference with common carriers, utilities, and institutions (such
as educational, governmental, or financial institutions), whenever the
defendant's conduct has affected or was likely to affect public service or
confidence".
------------------------------
End of VIRUS-L Digest [Volume 6 Issue 50]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253