From CUNYVM.CUNY.EDU!lehigh.edu!virus-l Fri Feb 5 08:45:04 1993 Date: Fri, 5 Feb 1993 08:33:25 -0500 Message-Id: <9302051229.AA28190@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V6 #19 Status: R 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: . 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 ------------------------------ Date: Wed, 03 Feb 93 13:52:40 -0500 From: Mario Rodriguez 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 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 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 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 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] *****************************************