To:	   VIRUS-L@LEHIGH.EDU
Subject:   VIRUS-L Digest V6 #19
--------
VIRUS-L Digest   Friday,  5 Feb 1993    Volume 6 : Issue 19

Today's Topics:

Re: Measuring polymorphism
Re: + - viuses
Re: What is a virus ?
Viruses and Worms
Checksums, CRCs, and other toys
Re: Sale of Viri
Unknow Virus (PC)
NAV questions (PC)
Dame virus (PC)
Re: New way of opening files??? (PC)
KRNL386.EXE erased (PC)
Re: Request for info: "ANSI bombs" in text files (PC)
Anyone has information about the Maltese Amoeba Virus? (PC)
Re: PKZIP 2'S AV is cracked (PC)
Re: Wide range unpacker available (PC)
Did someone has information about the Casino Virus? (PC)
Anybody knows the new address of Muttik I.G.?(Virus investigator)
Files on risc.ua.edu (PC)
ICVC'93 [icvc93@acmbul.bg (Organizing Comitee): ICVC'93]
Security and Privacy Symposium

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.sei.cmu.edu or upon request.) Please sign submissions with
your real name.  Send contributions to VIRUS-L@LEHIGH.EDU.
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:
<krvw@CERT.ORG>.

   Ken van Wyk

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

Date:    03 Feb 93 09:35:15 +0000
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: Measuring polymorphism

Malte_Eppert@f6050.n491.z9.virnet.bad.se (Malte Eppert) writes:

>Hi Frisk!

> >    MtE: 174 lines

>Wow! You managed to correctly scan any MtE mutation by using 174 wildcarded 
>scan strings?

No, I don't use any scan strings at all for it...I was talking about 174 lines
of C code.

- -frisk

- -- 
- --
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801

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

Date:    03 Feb 93 14:10:38 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: + - viuses

KARGRA@GBA930.ZAMG.AC.AT writes:

> ad a) If a program needs a viruslike program ( can be a worm too) to do what
>       is supposed to do, and the manuals state clearly, that there is a part
>       this software acting on its own, then I would not call this a virus in
>       common sense.

Hm, most software is "acting on its own"; I'm afraid that this needs a
better definition...

> ad b) If a program tries to hide by all means, then it is shurely a virus. Th
>       is somehow similar to some TSR's, but you can still use even the shurel
>       not very sophisticated "MEM" to see it.

But there are hundreds of viruses that are extremely stupid and do not
try to hide at all... Should we classify them as non-viruses?

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    03 Feb 93 13:48:58 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: What is a virus ?

WALKER@aedc-vax.af.mil (William Walker C60223 x4570) writes:

>      A computer virus is a sequence of instructions which, when 
>      executed under certain conditions, will make a functional 
>      duplicate of itself and will place this duplicate where it will 
>      intercept program execution at a later time under certain 
>      conditions, and may or may not return control to the original 
>      program execution at the point it was intercepted.  A virus may 
>      also have additional functions, but only the above functions are 
>      necessary for something to be called a virus.  

Hm, I see several problems with this definition:

1) As Dr. Cohen pointed out, "instructions" is not an appropriate
term. Use "symbols" instead.

2) After "certain conditions" I would add " or in a certain
environment".

3) Don't like the term "functional duplicate". As you explain further
in your message, you mean "a copy that might not look the same as the
original, but which does the same things". What if it doesn't do the
same things? I would argue that it is possible to make it do more
things and it is obvious that it is trivial to make it fewer things...
That's why I would prefer the term "possibly evolved copy" instead of
"functional duplicate".

4) What is "intercept program execution"? The non-resident viruses do
not intercept anything; they get executed only when the user runs the
infected program.

5) Don't like the term "executed". What about source files, macros,
BASIC programs? I would use the term "interpreted" or at least
"executed or interpreted" instead.

6) Since the virus may or may not return control to the original
infected program, is it worth the effort to include this in the
definition? Regardless whether it returns control to the program, it
will be a virus, if it matches the other parts of the definition.

So, let's try again:

"A computer virus is a sequence of symbols which, when interpreted
under certain conditions in certain environments, will make a possibly
evolved copy of itself. This is called `replication' and the copy
retains at least the capability to recursively replicate further."

Hm, still doesn't sound perfect to me, but I'll leave to the others to
improve it. And, according to it, DISKCOPY is still a virus...

> This definition seems to be free from subjectivity, so even Dr. Cohen 
> might agree with it. 

I strongly doubt that... :-)

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    Wed, 03 Feb 93 11:44:54 -0500
From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Viruses and Worms

IMHHO we seem to be going through some of the throes of an identity crisis 
with many partial discussions of "What is a virus ?" and "Is a worm a 
virus ?". This needs to be settled.

First, my opinion needs to be stated: A worm is not a virus. This is a
matter of definition and proofs can be generated either way depending
on definition. 

True, both propagate but in different ways: a worm is a stand-alone,
complete in itself and needing only to ensure regular scheduling using
available common resources found within a computing environment. The 
processes a worm creates are also separate and distinct entities within
that environment. Resources (e.g. compiler, linker) may need to 
be invoked to produce those entities, but will not be altered by it.

In counterpoint, a virus is a parasitic process: at some stage it involves
the replacement of part or all of a pre-existing or newly generated or 
potential process with itself. In other words, the scheduling or potential
for scheduling must already exist (e.g. like AUTOEXEC.BAT: nothing will be 
wrong if not there but the OS *was designed* to look for it & if found, will 
execute). No new scheduling was necessary. 

Bill was correct that the means for scheduling is the key - a worm creates
its own schedule for execution, a virus must use an existing one through 
replacement - a virus cannot schedule itself, it must have help. This IMHO is 
the fundamental difference and an important one since it is essential in 
drawing the envelope.

This resolves the question of MBR and BSI infections: the BIOS is programmed
to examine this area and, if certain criteria are met, to execute what is
found there - a pre-existing schedule for execution. Clearly, propagating
code in this area would be a virus and not a worm.

On the other hand, a process which copies itself onto a disk and modifies 
AUTOEXEC.BAT to execute it through a simple append operation would be a worm:
nothing was *replaced*. On the other hand, if AUTOEXEC.BAT were renamed A.BAT
and replaced with the malicious code as AUTOEXEC.BAT and the final line 
called A.BAT, this would be a virus - replacement occured. 

In simplest terms, a worm propagates through *addition* a virus propagates
though *replacement* (though it may reschedule the original to avoid 
detection).

					Chilly (8 C this morning),

							Padgett

ps I may shortly be rightsized 8*( - commercial, academic, or gov. leads 
   for a new synthesis would be apprecated. We also walk dogs.


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

Date:    Wed, 03 Feb 93 13:49:09 -0500
From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Checksums, CRCs, and other toys

From:    raph@panache.demon.co.uk (Raphael Mankin)
>This means that every CRC can be calculated with very few instructions
>per byte just by pre-computing a 256-entry table of 16- or 32-bit
>values.

Perhaps CRC is a poor choice of acronym since it has an explicit
meaning (but I was replying to another posting). "Checksum" is
probably better since we have been talking about computational means.
"Algorithmicly Generated Signature" (AGS) is even more appropriate. My
point was that *any* mechanism that is reasonably robust and which
will generate a well distributed scatter of values is sufficient. In
fact, the more the merrier.

					Warmer now,
							Padgett

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

Date:    03 Feb 93 19:06:10 +0000
From:    frisk@complex.is (Fridrik Skulason)
Subject: Re: Sale of Viri

johan@blade.stack.urc.tue.nl (Johan Wevers) writes:

>frisk@complex.is (Fridrik Skulason) writes:

>>As I have said before - the lack of any action against virus writers
>>is the primary reason why viruses are a problem today.

>Really? Then tell me, how would you take any legal action against virus
>writers? 

Did I mention *legal* action ?  No...I said just "any action"....this can
take several different forms, depending on who the virus author is - calling
his parents and asking them if they have any liability insurance might be
effective in some cases.  Publishing the names of the author might work
too. In some cases legal action may be the only way....but I am not saying
it is necessary in all cases.

>How would you even find them?

The same way you find other criminals.

- -frisk
- -- 
- --
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801

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

Date:    Tue, 02 Feb 93 20:21:27 +0000
From:    PROPE4@ifens01.insa-lyon.fr (Arnaud Thomas)
Subject: Unknow Virus (PC)

I've got a problem with my computer . Sometimes ASCII files change . There 
is letters which become other . When I use SCAN , i find no viruses .

Do someone know the virus ? What can I do ?

Thank you for your help 
Bye
Arno
- ------------------------------------------------------------------------------
THOMAS Arnaud
INSA Lyon
(FRANCE)

E-mail : prope4@ifens01.insa-lyon.fr
- ------------------------------------------------------------------------------

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

Date:    02 Feb 93 21:26:22 +0000
From:    balog@eniac.seas.upenn.edu (Eric J Balog)
Subject: NAV questions (PC)

Hi! I have two questions:

1) I have NAV 2.0 (included w/ NDW 2.0), and I just downloaded
nav20a10.exe from dorm.rutgers.edu. Does my version of NAV now check
for all of the viruses that NAV 2.1 checks for? (mine checks for 451
viruses/1159 strains)

2) Last week, someone posted a message comparing the effectiveness of
several anti-virus programs. Can anyone tell me how NAV rates as
compared to other anti-virus programs?

Any and all help will be *greatly* appreciated.

Thanks in advance.
Eric Balog                                  balog@eniac.seas.upenn.edu

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

Date:    Tue, 02 Feb 93 21:22:58 +0000
From:    cssiow@iastate.edu (Ching S Siow)
Subject: Dame virus (PC)

Hello, 

I would like to find out more about this "DAME Virus". My network has
3 files infected with this virus and would appreciate some help in
cleaning it out.  I have tried netscan and inoculan, both of which
failed to discover the virus.

Thanks in advance.

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

Date:    02 Feb 93 22:47:11 +0000
From:    phys169@csc.canterbury.ac.nz
Subject: Re: New way of opening files??? (PC)

Nemrod_Kedem@f101.n9721.z9.virnet.bad.se (Nemrod Kedem) writes:
>  > Why go so far? Did you here of writing to the disk via a port - instead
>  > of using standard interrupt method to write?
>  > I don't know of any A-V product that can monitor writing to ports,
>  > (unless it was a debugger that monitors every command that an
>  > application performs, and believe me: you don't want to use that!).
> 
> More then that: A product like the one you described will only work on 386,
> or higher, in protected mode....

Well, there are several ways to spot writing to the disk port directly.
Obviously, software-only methods would be limited in speed, which means
it is a good idea to have a dedicated machine for testing programs for
viruses (and compatibility) as they come into an organisation.

The methods are:

(1) Use a PC emulator (you can get the equivalent of about 6MHz easily on
    a Sparc, and the freeware program "pcm" looks promising in the long
    term - it already gives good diagnostics about port I/O).
(2) Use a Data General DG10 - old technology, but the 2nd processor traps all
    port I-O from the 8086 and can warn about naughty programs.
(3) Alarms attached to the write line of the disk cable (and variations on
    the theme, such as special disk controller cards).  These are about the
    best answer I guess - no impact on speed or compatibility, and catches
    everything because it can be impossible for viruses to detect.  There
    are a few drawbacks (most of which have been discussed before, but I'm
    happy to chat about them via e-mail).
(4) Software solutions based on the 386 facilities.
(5) Software solutions based on interrupts. 
(6) Software solutions based on making the physical disk layout obscure,
    e.g. encryption, strange head/sector numbers, compression algorithms,
    non-FAT systems in general.   But you might get a corrupted disk, rather
    than working - but infected - programs.
(7) Detection of viruses because they are much larger - having to carry around
    with them the extra code to access a variety of disk types and partitioning
    schemes.  The bigger the virus, the easier to detect (in general).  The
    days when everyone used IBM-compatible MFM drives with DOS 3 partitions
    have long gone.  My system, for example, uses IDE and SCSI drives, DM and
    DRDOS partitions, and sometimes SuperStore. 

Overall, I prefer viruses that do something out of the ordinary, like trying to
write to disk ports, since they become easy to distinguish from valid software.
The big problem with viruses on PC's, at least, at the moment is that there is
a large fuzzy area filled with programs (like Norton's DS and self-modifying
executables) that bypass DOS in the same way that viruses do - you have to
individually look at what they are doing and decide whether that is okay. There
are a few "clever" tricks like direct disk access that I genuinely hope virus
writers will adopt - in place of yet-another-stoned-hack and so on, and I think
that naming schemes which give too much glory to authors of slightly-changed
viruses should be changed to reflect that fact it is just another hack of
somebody else's idea. Even if string-scanners weren't being overtaken by virus
technology, the sheer nuisance factor of hundreds of slightly new viruses is
worth discouraging. (Hopefully this will generate some interesting discussion!)

Mark Aitchison.

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

Date:    Tue, 02 Feb 93 23:30:22 +0000
From:    ls8139@cis.ohio-state.edu
Subject: KRNL386.EXE erased (PC)

Hi there,
In comp.os.ms-windows.misc I was told that it is possible that
the reason I lost KRNL.EXE from my windows\system directory was
due to a virus.   If anyone knows of a virus that does this please
tell me.  I have scanned with Norton Desktop Antivirus and found
nothing.  

Should I get another scanner or is Norton AV good enough.
Thanks.


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

Date:    Wed, 03 Feb 93 05:55:16 +0000
From:    buhr@umanitoba.ca (Kevin Andrew Buhr)
Subject: Re: Request for info: "ANSI bombs" in text files (PC)

at974@cleveland.Freenet.Edu (Larry Bennett) writes:
|
|  [ reference to blurb regarding ANSI bombs ]
|
|  It sounds awful strange to me.  If I type out a text file that contains
|  one of these "bombs" do I face the risk of introducing a virus into
|  my system?

No.  Not unless you are running one *strange* ANSI driver.  The
"ANSI.SYS" driver that comes with DOS intercepts a number of control
codes when they are printed to the screen.  Some of these control
codes move the cursor, some delete characters and lines on the screen,
and some change the text or background colour.  One of these codes
redefines keystrokes, much like any keystroke-based macro package.

For example, by sending a special set of characters to the screen, one
could redefine the "i" key to simulate the keystrokes "^[DEL *.*^MY^M"
where "^[" is the Escape key and "^M" is the Enter key.  When the user
started to ask for a directory, the ANSI driver would intercept the
"i" key and "expand" it into an Escape (to cancel the current input),
a delete command, and confirmation for the delete command.

If I embed this special ANSI character sequence (the one to redefine
the key in the first place) in a text file, I can plant a primitive
sort of logic bomb in the form of a dangerous macro.  There is no ANSI
character sequence to get the ANSI driver to create or run a malicious
program however (other than what is already possible through keystroke
macros).

In theory, one *might* be able to have a key macro create a kind of
virus on-the-fly, but I can't see that being a particularly successful
sort of virus.

|  PKSFANSI.COM
|
|  PKSFANSI requires less than 1k bytes resident RAM, and should work
|  with any ANSI driver, such as the standard ANSI.SYS driver, NANSI,
|  ZANSI, DVANSI, etc.  Note that if you use a memory resident ANSI
|  driver, such as the DESQview DVANSI.COM driver, PKSFANSI should be
|  loaded after the ANSI driver is loaded.

I thought "NANSI" provided a command line option to disable key
reassignments anyway, but I could be wrong...

Kevin <buhr@ccu.UManitoba.CA>

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

Date:    Wed, 03 Feb 93 13:52:40 -0500
From:    Mario Rodriguez <EM436861@vmtecmex.bitnet>
Subject: Anyone has information about the Maltese Amoeba Virus? (PC)

I'm a virus researcher on Mexico City (Mexico), and I'm looking for
information about the Maltese Amoeba Virus (Irish). Does anybody had
FULLY analised it and have technical information about that virus?.
  I would appreciate any help.
                           Mario Rodriguez C.
                           I.T.E.S.M. C.E.M.
                           em436861 at vmtecmex.cem.itesm.mx
                           em436861 at rsserv.cem.itesm.mx
                           em436861 at itesmvf1.cem.itesm.mx


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

Date:    03 Feb 93 22:43:57 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: PKZIP 2'S AV is cracked (PC)

mikko.hypponen@compart.fi (Mikko Hypponen) writes:

> The computer undergound has been busy trying to crack the new
> AV-scheme. Now it has obviously been done. A file called
> MAKAV204.ZIP is circulating around the underground BBS's and with
> it anybody can secure an PKZIP 2 archive to any name.

Well, anybody who has the PUTAV program that comes with the registered
PKZIP 2 package could use it for AV cracking with just a few batch
files...

> To demonstrate this, I'm enclosing an UUencoded zip-file,
> which will show an AV to "Zip Source: McAFEE ASSOCIATES" when
> unpacked with PKUNZIP 2.04c.

Nah, this is not a good example of a cracked signature, see below.

> It should also be noted that the AV in above zipfile does not match
> the number shown before the authors name. McAfee's number should be #
> NWN405 (at least that was with pkzip 1.1). In fact this faked zip
> displays the number "# PKW655" which is the AV-number for PKWare
> itself. The cracker probably found a short-cut way by just changing
> the name and not the number.

A signature has three components - the number ("NWN405"), the company
name ("Zip Source: McAFEE ASOCIATES"), and the text that appears at
the end of the archive listing (normally put in the file AVEXTRA.TXT).
In your sample it seems that only the third part has been broken.

But it doesn't matter, because the authentication algorithm used by
PKWare -is- insecure and can be broken very easily. So, your warning
is correct - DON'T TRUST PKWARE'S -AV CODES - EVEN THOSE IN VERSION 2.

People who want -real- authentication of their archives, should look
at the archiver HPACK, available from garbo.uwasa.fi. It provides
public-key encryption and authentication, and is compatible with the
public keys used by the public key encryption program PGP.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    03 Feb 93 22:59:27 +0000
From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Wide range unpacker available (PC)

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:

> P.S. Well, the other purpose of this message is to check whether I am
> able to post public-key authenticated messages to comp.virus... :-)

Nope, I'm not... :-( Something iserts "- " in front of all lines that
begin with a dash, so PGP's markers become screwed up like that

> - -----BEGIN PGP SIGNED MESSAGE-----

And PGP refuses to recognize that the message contains a PGP block...
Of course, if you remove the "- " in front of each line, the resulting
message will check OK. But this is too inconventient - you cannot just
pipe the article through PGP when you want to verify its
authenticity... :-(

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany

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

Date:    Wed, 03 Feb 93 21:09:43 -0500
From:    Mario Rodriguez <EM436861@vmtecmex.bitnet>
Subject: Did someone has information about the Casino Virus? (PC)

My name is Mario Rodriguez and I'm a virus researcher in Mexico City. I'm tryin
g to find information about the Casino virus. I know the virus display a messag
e on the screen when it activates on January 15, April 15 and August 15, and I
have the text it presents. I would like to know if someone has the EXACT screen
 that the virus presents and some TECNICAL information about this virus.
         If you have any information please contact me at any of the following
addresses:  em436861 at vmtecmex.cem.itesm.mx
            em436861 at vmtecmex       (this is in bitnet)
            em436861 at rsserv.cem.itesm.mx
            em436861 at itesmvf1.cem.itesm.mx
                         Mario Rodriguez


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

Date:    Wed, 03 Feb 93 15:36:56 -0500
From:    Mario Rodriguez <EM436861@vmtecmex.bitnet>
Subject: Anybody knows the new address of Muttik I.G.?(Virus investigator)

I had just read an old article in virus-l about the virus Starship.
This article was written by Muttik I.G., its old internet address was
'MIG@politon.msk.su', but the node had disappear. I think he is a
researcher in Moscow, in the actu al Comunity of Independent States
(RUSIA).
     If anybody have information about him please contact me at:
                        em436861 at vmtecmex.cem.itesm.mx
                        em436861 at vmtecmex      (in bitnet)
                 Mario Rodriguez
                 I.T.E.S.M. C.E.M.  (Mexico)

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

Date:    Wed, 03 Feb 93 13:51:26 -0500
From:    James Ford <JFORD@UA1VM.UA.EDU>
Subject: Files on risc.ua.edu (PC)

Here is the current list of files on risc.ua.edu (130.160.4.7).
Please let me know if some are out of date or if I'm missing some.

McAfee's v100 series has been uploaded, as well as vsig9301.zip.

- -- jf

- ------------------------------------------------------------------
0files.9302       ds115.zip         secur235.zip      virdt100.zip
20a10.zip         fixutil3.zip      sentry02.zip      virlab15.zip
Valert-l.readme   fp-206a.zip       stealth.zip       virpres.zip
Virus-l.faq       fshld15.zip       tbav503.zip       virsimul.zip
Virus-l.readme    fsp_184.zip       tbavx503.zip      virstop.zip
aavirus.zip       hack1192.zip      trapdisk.zip      virusck.zip
asig9301.zip      hs32.zip          unvir902.zip      virusgrd.zip
avs_e224.zip      htscan19.zip      uxencode.pas      virx26.zip
bbug.zip          i-m131.zip        v-faq.zip         vkill10.zip
bootid.zip        innoc5.zip        vacbrain.zip      vshell10.zip
catchm16.zip      killmonk.zip      vaccine.zip       vshld100.zip
catchm18.zip      m-disk.zip        vaccinea.zip      vsig9214.zip
ccc91.zip         msg_9_12.zip      validat3.zip      vsig9301.zip
chk.zip           mtetests.zip      validate.crc      vstop54.zip
chkint.zip        netsc100.zip      vc300ega.zip      vsumx212.zip
clean100.zip      nshld104.zip      vc300lte.zip      vtac48.zip
cvc792am.zip      oclean99.zip      vcheck11.zip      vtec30a.zip
cvc792ma.zip      onetsc99.zip      vchk23b.zip       wcv201.zip
cvc792ms.zip      oscan99.zip       vcopy82.zip       wp-hdisk.zip
cvcindex.zip      pkz110eu.exe      vdetect.zip       wscan100.zip
dir2clr.zip       scanv100.zip      vds210t.zip       ztec61b.zip


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

Date:    Tue, 02 Feb 93 17:48:55 +0000
From:    icvc93@acmbul.bg (Organizing Comitee)
Subject: ICVC'93 [icvc93@acmbul.bg (Organizing Comitee): ICVC'93]

              C A L L        F O R      P A P E R S

   ACMBUL's FIRST INTERNATIONAL COMPUTER VIRUS PROBLEMS AND
                  ALTERNATIVES CONFERENCE

           5-8 April, 1993     -     Varna, Bulgaria

The   purpose  of  the  1993  International  Computer  Virus
Conference is to provide  a  forum  for  anti-virus  product
developers,   researchers   and   academicians  to  exchange
information  among  themselves,  students  and  the  public.
ICVC'93  will  consist of open forums, distinguished keynote
speakers, and  the  presentation  of  high-quality  accepted
papers.   A  high degree of interaction and discussion among
Conference participants  is  expected,  as  a  workshop-like
setting is promoted.

Because   ICVC'93   is   a  not-for-profit  activity  funded
primarily  by  registration  fees,  all   participants   are
expected to have their organizations bear the costs of their
expenses and registration.  Accomodations will be  available
at reduced rates for confernece participants.

WHO SHOULD ATTEND

The   conference   is   intended   for   computer   security
researchers,  managers,  advisors,  EDP  auditors,   network
administrators,  and help desk personnel from government and
industry,  as   well   as   other   information   technology
professionals interested in computer security.


CONFERENCE THEME

This  Conference,  devoted  to advances in virus prevention,
will encompass developments in  both  theory  and  practice.
Papers   are   invited   in  the  areas  shown  and  may  be
theoretical, conceptual, tutorial or descriptive in  nature.
Submitted  papers  will  be refereed, and those presented at
the Conference will be included in the proceedings.


Possible  topics  of  submissions  include,  but   are   not
restricted to:

 o  Virus Detection                    o  Virus Trends and Forecast
 o  Virus Removal                      o  Virus Prevention Policies
 o  Recovering from Viruses            o  Incident Reporting
 o  Viruses on various platforms       o  Emergency Response
    (Windows, Unix, LANs, WANs, etc.)  o  Viruses and the Law
 o  Virus Geneology                    o  Education & Training


THE REFEREEING PROCESS

All  papers  and  panel proposals received by the submission
deadline and which  meet  submission  requirements  will  be
considered for presentation at the Conference.

All  papers  presented  at  ICVC'93  will be included in the
Conference proceedings, copies of which will be provided  to
Conference  attendees.   All  papers presented, will also be
included in proceedings to be published by the ACMBUL.


INSTRUCTIONS TO AUTHORS

        [1]  Two (2) copies of the full paper, consisting of
up-to   20   double-spaced,   typewritten  pages,  including
diagrams, must be received no later than 28 February 1993.

        [2]  The language of the Conference is English.

        [3]  The first page of the manuscript should include
the title of the paper, full  name  of  all  authors,  their
complete   addresses   including  affiliation(s),  telephone
number(s) and e-mail address(es), as well as an abstract  of
the paper.


IMPORTANT DATES

    o Full papers to be received in camera-ready form by the
Organizing Committee by 28 February 1993.

    o  Notification of accepted papers will be mailed to the
author on or before 10 March 1993.

    o Conference:  5-11 April 1993,  St. Konstantine Resort,
Varna, Bulgaria


WHOM TO CONTACT

Questions  or  matters  relating  to  the Conference Program
should be directed to the ACMBUL:

        ICVC'93
        Attn:  Mr. Nickolay Lyutov
        ACMBUL Office
        Varna University of Economics
        77 Boris I Blvd, 9002 P.O.Box 3
        Varna
        Bulgaria

Phone/Fax:  (+35952) 236-213
E-mail: ICVC93@acmbul.bg

icvc93@acmbul.bg (Organizing Comitee)
ACMBUL -- Bulgarian Chapter of ACM

icvc93@acmbul.bg (Organizing Comitee)
ACMBUL -- Bulgarian Chapter of ACM

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

Date:    Wed, 03 Feb 93 12:09:04 -0800
From:    Teresa Lunt <lunt@csl.sri.com>
Subject: Security and Privacy Symposium

	1993 IEEE SYMPOSIUM ON RESEARCH IN SECURITY AND PRIVACY


May 24-26, 1993
Claremont Resort,
Oakland, California

Sponsored by the
IEEE Technical Committee on Security and Privacy
In cooperation with the
International Association of Cryptologic Research

Symposium Committee
Teresa Lunt, General Chair
Cristi Garvey, Vice Chair
Richard A. Kemmerer, Program Co-Chair
John Rushby, Program Co-Chair


			PRELIMINARY PROGRAM

MONDAY

9:00--9:30:	Welcoming Remarks: Teresa Lunt and Dick Kemmerer

9:30--10:30:	VIRUSES AND INTRUSION DETECTION   Doug McIlroy, Session Chair
  9:30--10:00:	Measuring and Modeling Computer Virus Prevalence
			Jeffrey Kephart and Steve White
 10:00--10:30:	USTAT: A Real-Time Intrusion Detection System for UNIX
			Koral Ilgun

10:30---11:00:	BREAK

11:00--12:00:	CAUSALITY AND INTEGRITY:  George Dinolt, Session Chair
  11:00--11:30:	Preventing Denial and Forgery of Causal Relationships 
		in Distributed Systems
			Michael Reiter and Li Gong
  11:30--12:00: Message Integrity Design
                        Stuart Stubblebine and Virgil Gligor


12:00--2:00:	LUNCH

2:00--3:30:     PANEL: Privacy Enhanced Mail
                        Panelists: TO BE ANNOUNCED

3:30--4:00:	BREAK

4:00--5:00:	AUTHENTICATION PROTOCOLS:  Teresa Lunt, Session Chair
  4:00--4:30	Authentication Method with Impersonal Token Cards
			Refik Molva and Gene Tsudik
  4:30--5:00:	Interconnecting Domains with Heterogeneous Key 
		Distribution and Authentication Protocols
			Frank Piessens, Bart DeDecker and Phil Janson

6:00:	POSTER SESSIONS


TUESDAY

9:00--10:30:	TIMING CHANNELS: John Rushby, Session Chair
   9:00-- 9:30:	Modelling a Fuzzy Time System
			Jonathan Trostle
   9:30--10:00:	On Introducing Noise into the Bus-Contention Channel
			James Gray
  10:00--10:15:	Discussant:  TO BE ANNOUNCED
  10:15--10:30:	Open Discussion

10:30--11:00:	BREAK

11:00--12:00:	INFORMATION FLOW: John McLean, Session Chair
  11:00--11:30	A Logical Analysis of Authorized and Prohibited 
		Information Flows
			Frederic Cuppens
  11:30--12:00	The Cascade Vulnerability Problem
			J. Horton, R. Harland, E. Ashby, R. Cooper,
			W. Hyslop, B. Nickerson, W. Stewart, and K. Ward

12:00--2:00:	LUNCH

2:00--3:30:	PANEL: The Federal Criteria
			Panelists: TO BE ANNOUNCED

3:30--4:00:	BREAK

4:00--5:00:	DATABASE SECURITY:  Marv Schaefer, Session Chair
  4:00--4:30:	A Model of Atomicity for Multilevel Transactions
			Barbara Blaustein, Sushil Jajodia, 
			Catherine McCollum and LouAnna Notargiacomo
  4:30--5:00:	Achieving Stricter Correctness Requirements in 
		Multilevel Secure Database
			Vijayalakshmi Atluri, Elisa Bertino and
			Sushil Jajodia

5:00:	TC MEETING

6:00:	POSTER SESSIONS


WEDNESDAY

9:00--10:30:	ANALYSIS OF CRYPTOGRAPHIC PROTOCOLS:  Yacov Yacobi, Session Cha
ir
   9:00-- 9:30:	Trust Relationships in Secure Systems 
		-- A Distributed Authentication Perspective
			Raphael Yahalom, Birgit Klein and Thomas Beth
   9:30--10:00:	A Logical Language for Specifying Cryptographic 
		Protocol Requirements
			Paul Syverson and Catherine Meadows
  10:00--10:30:	A Semantic Model for Authentication Protocols
			Thomas Woo and Simon Lam

10:30--11:00:  BREAK

11:00--12:00:	SYSTEMS: Virgil Gligor, Session Chair
  11:00--11:30:	Detection and Elimination of Inference Channels 
		in Multilevel Relational Database Systems
			X. Qian, M. Stickel, P. Karp, T. Lunt and 
			T. Garvey
  11:30---12:00	Assuring Distributed Trusted Mach
			Todd Fine

12:00:		SYMPOSIUM ADJOURN

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

Symposium Registration: Dates strictly enforced by postmark.

Advance Member (to 4/12/93) $240*

Late Member (4/13/93-4/30/93) $290*

*Registration must include IEEE number to qualify.

Advance Non-Member $300
Late Non-Member    $370

Advance Student    $50
Late Student       $50


Mail registration to:
		Cristi Garvey
		R2/2104
		TRW Defense Systems Group
		One Space Park
		Redondo Beach, CA 90278
		(310) 812-0566


NO REGISTRATIONS BY EMAIL

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

End of VIRUS-L Digest [Volume 6 Issue 19]
*****************************************
