HDTenEightyP/NetNews huggingface dataset:
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Joshi Question (PC)
Date: 7 Jan 93 20:10:19 GMT

rind@enterprise.bih (David Rind) writes:

> Does Joshi trap attempts at warm reboots?  There was an intermittent
> problem with a new program on a computer that turned out
> to be infected with Joshi.  The problem was sporadic enough that I
> can't be certain that getting rid of Joshi eliminated it, but if
> Joshi was trapping Alt-Ctrl-Del, then that would explain the "bug".

Yes, Joshi intercepts INT 9 (the keyboard interrupt) and checks for
Alt-Ctrl-Del. If it is detected, the virus tries to "survive the warm
reboot". That is, it clears the screen, restores the interrupt vectors
it has saved while it has been loaded in memory, and issues INT 19h.
This will actually reboot the computer without cleaning the memory,
thus the virus will not be destroyed.

A careful user will not be fooled by that, because most machines
display a lot of messages during the warm reboot. These messages come
from the BIOS. Unfortunately, this is not reliable enough, because
most people are not careful and will not make the difference between a
real warm reboot and the virus just blanking the screen (i.e., no
messages). On the top of that, some computers (mainly true IBM PC or
PS/2s) do not display any messages during the warm reboot...

This has created the myth that some viruses are able to survive a warm
reboot. They cannot, or at least they cannot do this unnoticeably on
most computers, but nevertheless you are always advised to cold-boot
when you suspect a virus in memory...

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
From: riordan@tmxmelb.mhs.oz.au (Roger Riordan)
Newsgroups: comp.virus
Subject: Clearing out old signatures (PC)
Date: 7 Jan 93 01:34:25 GMT

padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) wrote recently

> Enclosed is a DEBUG script that will create a 68 byte .COM file
> (CLEAR.COM) that will zero out memory between the current load
> position and the TOM. To use, ...

The only trouble with this is there is a surprising amount of 
software which leaves active code in memory, but does not bother to 
tell DOS.   

To guard against possible unknown viruses like to Chinese Fish, 
which install themselves in high memory, but do not set the top of 
memory down, we recently added a feature to VET to fill unused 
memory with a diagnostic procedure which gives a warning message, 
and locks the PC, if anything attempts to execute unused memory.  So 
if you run VET, and an unknown virus of this type is already in 
memory, you get the warning as soon as VET calls an interrupt the 
virus has trapped.

Ahh! Another loophole closed!  Unfortunately a big customer 
immediately complained some users could no longer log in.  

We investigated, & found that they were using Microsoft Lan Manager.  
When PROTMAN was run from CONFIG.SYS a block of code was installed 
at 7000:7800, but top of memory (as recorded at offset 2 in the PSP) 
remained 9FFF:0000.  If this code was overwritten by running VET (or 
anything else) before the user logged in, the system would crash 
when the program NBP.EXE was run as part of the log in procedure.

We sent details of this to MicroSoft Support, but, naturally, never 
received any reply.

We added an option to VET to disable this feature.  A significant no. 
of users have encountered similar problems.  Most have been using 
Lan Manager, but other programs may also have been involved.

Roger Riordan                     riordan.cybec@tmxmelb.mhs.oz.au

CYBEC Pty Ltd.                                 Tel: +613 521 0655
PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: +613 521 0727
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: Vshield vs Virstop (PC)
Date: 7 Jan 93 13:44:59 GMT

bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes:

> There are several problems with the integrity checking by Scan, and 
> Vshield.
>  
> 1. Some programs will not run after the CRC is added to the file. So it is 
>    necessary to remove the CRC. Scan filename /RV will remove the CRC.

Yes, but there is another option, which puts the checksums in a
separate file, instead of attached to the checksummed executables.
Nevertheless, there are much more serious problems:

> 2. These CRCs will not detect stealth infectors because stealth viruses 
>    disinfects infected files when an infected file is opened for any 
>    reason.

> 3. These CRCs will not detect the presence of companion infectors because 
>    these companion infectors do not attach to files.

  4. The particular CRCs used are trivial to forge.

  5. The integrity checker is not aware of many of the existing
attacks against integrity checking software (described in my paper).
You mentioned two of them - stealth viruses and companion viruses, but
there are many more and almost any of them can be used to bypass the
integrity checking of VShield.

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
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: os2-stuff (OS/2)
Date: 5 Jan 93 22:25:57 GMT

KARGRA@GBA930.ZAMG.AC.AT writes:

> as pointed out in point 10 at least *.dll and *.drv files contain code which
> cannot be executed by the user, but is loaded and executed as any other *.ov?
> As there are viruses which infect overlays, they can be infected in a similar
> way.

Could somebody check how exactly the DLL and DRV files are loaded in
OS/2? The only reason that "some viruses can infect overlays" is that
they infect on INT 21h/AH=4Bh, instead of INT 21h/AX=4B00h. Since some
overlays are loaded with INT 21h/AX=4B03h, a sloppy written virus
could infect them by mistake. How are the DLL and DRV files loaded in
OS/2? If they are not loaded using any INT 21h/AX=4Bxxh function, then
it is rather unlikely that any of the currently known viruses will
infect them...

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
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Newsgroups: comp.virus
Subject: Re: Vshield vs Virstop (PC)
Date: 29 Dec 92 00:28:00 GMT

Quoting from Vesselin Bontchev to All About Re: Vshield vs Virstop (P on 
12-09-92

VB> BTW, I think that there is a way to tell Vshield to use the EMS if yo
VB> have some. This is a feature that Virstop doesn't have yet. Vshield

Vesselin:
 
Vshield doesn;t go into EMS. It can be loaded high in upper memory blocks. 
However. this is done with the /LH parameter. Vshiels will not work if 
users use LOADHIGH from DOS 5.0 or LOADHI in QEMM or some other memory 
manager.

VB> has also some other features, like an attempt to do on-line integrity
VB> checking, but this is not implemented well enough.

There are several problems with the integrity checking by Scan, and 
Vshield.
 
1. Some programs will not run after the CRC is added to the file. So it is 
   necessary to remove the CRC. Scan filename /RV will remove the CRC.
 
2. These CRCs will not detect stealth infectors because stealth viruses 
   disinfects infected files when an infected file is opened for any 
   reason.

3. These CRCs will not detect the presence of companion infectors because 
   these companion infectors do not attach to files.

Bill

- ---
 * WinQwk 2.0 a#383 * JULY 13TH activates Jul 13th
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Newsgroups: comp.virus
Subject: Re: Invalid Boot Sectors (PC)
Date: 5 Jan 93 22:58:25 GMT

>From:    "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>

>I recently wrote

>>In a recent comment on a query by MOPURC01@ULKYVM.LOUISVILLE.EDU 
>>(Michael Purcell) about a virus which allegedly made disks 
>>unreadable I wrote.

>>> If you put the wrong byte in the wrong place you can get the 
>>> symptoms described.  ...

>It appears the original message got lost, but the gist was that, 
>IN THEORY, it is possible to write a BS virus which is invisible 
>on an infected PC, but impossible to detect on an uninfected PC 
>with any existing scanner because DOS will crash if any attempt is 
>made to access an infected disk. 

This is something that experimentation has been done on. What I have
found is that:

a) If the Partition table is missing certain DOS signature bytes, DOS
   will refuse to recognise the disk (but a floppy boot will still work).

b) If certain bytes in an otherwise good P-Table have certain wrong values
   a floppy boot may hang (which bytes and what values are DOS version
   dependant).

c) Even given (a) or (b), BIOS software can restore bootability (I have
   a version of FIXMBR that loads and runs from the BIOS just like
   the early Microsoft Flight Simulator).

d) *Every* MBR infection that I have seen is detectable if you
   look in the right places. "Stealth" can always be bypassed with a
   direct BIOS call.

In other words, every infection I have seen is recoverable with the
right tools (usually DEBUG, FDISK, & SYS). Sometimes it is not worth
the bother since repair via E-Mail is somewhat more difficult, but
whatever is not corrupted can be retrieved and that which has been
corrupted can usually be restored. In general I have found that the
stupider the program, the more likely it will work.

I am glad that the above said "IN THEORY" since an undetectable,
invisible virus that can make a system completely unbootable except 
from the hard disk just cannot exist. (Note, I am not including
access control programs that encrypt the whole disk and rely on
input of the key by the user for decryption - this could be made
"strong enough" - but a self-contained program cannot. Period.

		82 today - what Floridians put up with summer for, 
						Padgett
From: CSCRDW%CURIE@vaxtm1.rtpnc.epa.gov (Ron Whittle)
Newsgroups: comp.virus
Subject: A-V virus
Date: 7 Jan 93 15:36:10 GMT

On Tue, 22 Dec 92, Suzana wrote:

S> Suppose that we have an A-V product which in regular intervals or
S> randomly send a virus in system. Virus (fast infector) infects only
S> programs which checksum doesn't correspond to previously calculated
S> values. If no such program is found virus deletes itself or removes
S> from memory. If changed program found virus activates scanner to check
S> if there is any known virus.  If known virus is found message is sent
S> to the user. If program is changed and no known virus is found the
S> message is sent to the user to make decision.  If decision is to leave
S> program as is, virus cuts itself from the program.  The whole process
S> (except messages) takes place in background. There is no need for all
S> A-V program (which is combination of I-checker and scanner) to be TSR,
S> only virus is occasionally TSR. 

This looks interesting, but you might run into performance problems
as the 'good virus' looks for non-infected programs.  Also, if you
had a stealth virus that was already active in memory, when your
virus infects a file, it might overwrite part of the program code (or
the stealth virus, depending on infection method), causing you to
lose the program.

Wouldn't this program be easier as a TSR?  That way it wouldn't have
to infect the files, and only needs to check programs that you
actually execute.

S> There is slight similarity in this
S> idea with reaction of human immunity system. Anyone has ethical
S> problem with her/his own immunity system ?

Actually, yes.  Since my immunity system makes periodic attempts to
kill me, in the name of protecting me, I do have a problem with it. 
You see, I am one of those unfortunate people who are allergic to
bees.  Each time I am stung, my immune system makes a faster and
harsher response, and one day this will kill me if I do not get
medical help.  Is it possible that the A-V virus might (accidentally)
act in the same way?

- ---
Ron Whittle
cscrdw%curie@epavax.rtpnc.epa.gov
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Newsgroups: comp.virus
Subject: Filler virus (PC)
Date: 28 Dec 92 23:21:00 GMT

Quoting from Brill@aecom.yu.edu to All About Filler virus (PC) on 12-07-92

B > 	Scan 99 detected "Filler" active in the memory of my computer.
B > When I booted from a write-protected floppy the nasty virus was not
B > found, no matter how many times I tried.  By the way, I have CPAV
B > constantly running and it did not detect anything wrong.

You have probably already received many answers, but I will add my two 
cents any way.
 
The problem is the VSAFE or VWATCH TSRs that comes with CPAV. The virus 
signatures are not encrypted when these TSRs are in memory, and Scan finds 
the signature, and assumes the rest of the virus is there. 

You have several options.
 
A. Use CPAV exclusively.
B. Stop using CPAV.
 
In my tests, these scanners rank highest.
 
F-Prot from Frisk Software
VIRx from Data Watch Software (Used to be Microcom)
McAfee's Scan.

Bill

- ---
 * WinQwk 2.0 a#383 * HALLOWEEN activates Oct 31st
From: RADAI@vms.huji.ac.il (Y. Radai)
Newsgroups: comp.virus
Subject: Re: Integrity Management
Date: 7 Jan 93 14:59:12 GMT


  In reply to me, Vesselin Bontchev writes:
>>          First, you write as if all algorithms have a seed.
>
> My initial thought was that the database of checksums is kept on-line.
> If it isn't (i.e., if it is stored on a write-protected diskette),
> then you don't need any cryptographic checksum, of course. But if it
> is, you cannot just use plain MDx or any other known keyless
> algorithm, because a virus could use the same algorithm to compute the
> new checksum of the infected file and update the database of checksums,
> so that everything will look OK... In these cases, you -must- have
> some kind of key that is kept unknown to the virus.

Since this is essentially the same as what I have written several times,
I guess I can't very well object to it, can I?  :-)

>>                 But what do you mean by "using a different seed for
>> the checksum" in the case of CRC?
>
> Well, a CRC is usually computer like this:
>
> 	crc = INITIAL_VALUE;
>   	while ((c = getc (file)) != EOF)
>		crc = crc_table [(crc & 0x00FF) ^ c] ^ (crc >> 8);
>
> Usually INITIAL_VALUE is 0, but you could set it to anything you would
> like...

Well, I think that comes from using a particular (table-driven) *im-
plementation* of CRC, and is not an essential feature of CRC as it
is defined.  Also, while I agree that in this implementation
INITIAL_VALUE could be considered as a seed, I doubt that varying this
value adds any security, since CRC can be made key-dependent in a
very natural way (by varying the generator) and since, in a certain
sense, it is then provably secure (subject to certain reasonable
assumptions).

>>   More important, in the case of MDx and X9.9, how do you know that
>> varying the seed is enough?
>
>You are right, I don't know whether it is secure enough. But you have
>to do something with the keyless algorithms, if you want to achieve
>different checksums for each user and not allow the virus to guess the
>correct checksum of the modified object...

But why is it necessary to do something with keyless algorithms at
all?  There is an alternative to varying a seed (or artificially
introducing a key) in a keyless algorithm, and that is to use an
algorithm which is key-dependent by its very design (such as the MAA
of ISO 8731-2 or ANSI X9.9, if one wants a cryptographic algorithm).
  I'm not saying that the latter alternative is necessarily better
than the former.  Regardless of which is used, the important criteria
are security and speed, where "security" means mainly the requirement
that, given a file (without knowledge of the key or seed), it be com-
putationally infeasible to create another file with the same checksum
as the given one.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     RADAI@HUJIVMS.BITNET
                                     RADAI@VMS.HUJI.AC.IL
From: kovarski@zooid.guild.org (Mark Kovarski)
Newsgroups: comp.virus
Subject: Info on 1575 Virus Needed (PC)
Date: 31 Dec 92 23:31:28 GMT

Since I do not have FTP access intil early 1993, can someone provide
me information on the 1575 Virus. I remember seeing a Database which
is maintained by a german University that had great technical
information about every Virus. Could someone copy the portion about
the 1575 Virus and post it here. Also, what anti-virus programs can
detect it and remove it? I would *GREATLY* appreciate it.

Sincerely,
Mark K.
Happy New Year to All.
E-Mail: kovarski@zooid.guild.org
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Newsgroups: comp.virus
Subject: noint - what is it? (PC)
Date: 29 Dec 92 07:40:00 GMT

Quoting from Gang Wu to All About noint - what is it? (PC) on 12-23-92

GW> anyone has any idea what noint virus is? we discovered several of the
GW> here in barnard college and it seemed that the virus can physically
GW> destroy the floppy disk (all the disks we found infected by this viru
GW> has numerous bad sectors after the infection.)

No-Int is a stealth boot sector virus. Sometimes called Stoned 3.

This is the virus that was accidentaly distributed by Novel about a year 
ago.
 
Bill

- ---
 * WinQwk 2.0 a#383 * MICHELANGELO activates Mar 6th
From: jack@csn.org (Jack Davis)
Newsgroups: comp.virus
Subject: DOS Serial Numbers (PC)
Date: 7 Jan 93 04:44:33 GMT

Regarding the question of changing the SERIAL NUMBER of a DOS disk.
An undocumented DOS function 69h which will GET or SET the serial
number of a disk is discussed in PC Magazine, July 1992, V11N13, Page
496.  A PASCAL program listing is included with the article and the
program itself is avaiable from PC Magazine.

Regards,

Jack Davis
jack@csn.org
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Newsgroups: comp.virus
Subject: MS-DOS CHKDSK & VER /R (PC)
Date: 29 Dec 92 06:37:00 GMT

Quoting from A. Padgett Peterson to All About MS-DOS CHKDSK & why VER / on 
12-20-92

AP> Further, COMP finds no difference between this COMMAND.COM and the on
AP> just expanded from a new set of distribution disks that is dated 11-1

Just for your information, FC (File Compare) does a better job at 
comparing files than COMP.

Bill

- ---
 * WinQwk 2.0 a#383 * SURIV 3.0 activates Friday the 13th
From: jwright@cfht.hawaii.edu (Jim Wright)
Newsgroups: comp.virus
Subject: Unix security archive sites last changed 21 August 1992
Date: 3 Jan 93 01:07:25 GMT

Unix security archive sites		last changed 21 August 1992

cert.org
	Ken van Wyk <krvw@cert.org>
	Accessible through anonymous ftp, IP number 192.88.209.5
	A number of directories can be found in ~ftp/pub/tools.

funic.funet.fi
        Jyrki Kuoppala <jkp@cs.hut.fi>
        Accessible through anonymous ftp, IP number 128.214.6.100.
        Directory pub/unix/security contains programs to help in
        security, pub/doc/security contains various documents about
        security in general and unix security (like the worm
        documents)

wuarchive.wustl.edu
        Chris Myers <chris@wugate.wustl.edu>
        Accessible through anonymous ftp, IP number 128.252.135.4.
        A number of directories can be found in ~ftp/usenet/comp.virus/*.
From: fc@turing.duq.edu (Fred Cohen)
Newsgroups: comp.virus
Subject: New security service
Date: 7 Jan 93 12:35:44 GMT


	Protection Experts is starting an evaluation of efficacy of
antivirus products.  This evaluation is designed to indicate to the end
user, how effective each product would be in the real-world environment
over different periods of time.

	We have a lot of initial data already, and are planning to
release an initial version of our report next week.  Any anti-virus
product vendor who would like to participate should send computer mail
to me, or FAX Protection Experts at 412-422-4135 or 907-344-3069.  We
will need vendors to fill out a survey, and provide us with historical
copies of their products and literature from the last several years. 

	Our surveys will include Mac, PC under DOS, PC under Windows,
OS/2, PC under Unix, Netware, TCP/IP,  LANTastic, Workgroup, AppleTalk,
System/7, AppleShare, and any other environments provided to us.  If
you are interested in providing any other environments to us for this
work, please contact us.

__________________________________________________________________________
	Protection Experts - Your Experts in Information Protection
8:30AM-2PM Eastern					2PM-7:30PM Eastern
412-422-4134						      907-344-5164
	     24 Hour FAX Service 412-422-4135 OR 907-344-3069
__________________________________________________________________________
From: celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta))
Newsgroups: comp.virus
Subject: Definition of computer virus (was FC on virus creation)
Date: 22 Dec 92 19:29:28 GMT

Hello everybody,

I was following for some time discussion about ethical correctness of
Fred Cohen's virus creation. It seems to me that most of dilemmas
arises from different understanding of term computer virus. I am
relatively new on this list, so don't know if the definition of
computer virus was properly discus- sed earlier and if some general
definition was accepted. If was I would like to know which one. I saw
different definitions in literature (I looked in the VIRUS-L FAQ too
:-))and would like to sublime what I've read till now in following
statement :

      Computer virus is set of instruction written with intention to
cause some unwanted function in system in which is currently situated.
Virus has ability of reproduction, it can propagate through different
media, may evolve over time and can mutate.

Is that correct definition ? I would really like to know one which
wouldn't lead to misunderstandings.
                                                                           
 Cheers,                                       ______________              
                                              |              |             
 Suzana                                      /|  Who am I ?  |             
                                 /~~~~~~\~\ / |______________|            
                                (  * *   )/            
                               /(  ___   )                                 
                              ~  \______/                                  
                                @/       \@       

- ---------------------------------------------------------------------------
Address: Suzana Stojakovic-Celustka          e-mail addresses:
         Department of Computers             celustka@sun.felk.cvut.cs
         Faculty of Electrical Engineering   celustkova@cs.felk.cvut.cs
         Karlovo namesti 13
         12135 Prague 2                      phone : (+42 2) 293485   
         Czechoslovakia                      fax : (+42 2) 290159