Return-Path: <[email protected]>
Received: from csmes.ncsl.nist.gov (MACBETH.NCSL.NIST.GOV) by csrc.ncsl.nist.gov (4.1/NIST)
       id AA10940; Fri, 11 Sep 92 16:21:37 EDT
Posted-Date: Fri, 11 Sep 1992 16:08:31 -0400
Received-Date: Fri, 11 Sep 92 16:21:37 EDT
Errors-To: [email protected]
Received: from CS2.CC.Lehigh.EDU by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm))
       id AA26046; Fri, 11 Sep 92 16:15:18 EDT
Received: from  (localhost) by CS2.CC.Lehigh.EDU with SMTP id AA26555
 (5.65c/IDA-1.4.4); Fri, 11 Sep 1992 16:08:31 -0400
Date: Fri, 11 Sep 1992 16:08:31 -0400
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 V5 #151
Status: R
VIRUS-L Digest   Friday, 11 Sep 1992    Volume 5 : Issue 151

Today's Topics:

Re: Tan An Door virus?!?! (PC)
Re: NetWare and viruses - some new results (PC)
Re: Tan an Door virus?!?! (PC)
Netware Rights again (PC)
F-PROT 2.05 - minor problem detected. (PC)
Re: F-prot false alarm? (PC)
Re: New files on eugene and beach (PC)
Problem with Vshield 5.1B95 (PC)
Netware (PC)
NAVSCAN (PC)
Re: NetWare and viruses - some new results (PC)
Re: VACSINA Information Wanted (PC)
Re: F-Prot & SuperStor (PC)
Re: F-PROT reports Bugsres 3 Jokes program? (PC)
Now I know I have something. (PC)
Re: A new virus????? HELP! (PC)
Re: Auto-detecting Virus (PC)
Re: Looking for references (UNIX)
Virus scan for AIX 3.2? (UNIX)
Re: self-checking programs
Self-modifying programs
Re: Comp Virus Conferences ... THE BEST CONFERENCE THIS YEAR!

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 [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

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

Date:    Wed, 09 Sep 92 22:32:33 -0400
>From:    Anthony Naggs <[email protected]>
Subject: Re: Tan An Door virus?!?! (PC)

Paul Bradshaw, <[email protected]>, asked for information about a virus
described in his local virus conference:
> Title: Tan An Door Virus
>
> Recently in China I cought the
> 64 VIRUS
> which apparently was related to the incident of June 4 atthe Square of
> Tan An Door in Peijiang (Bejing ?).

64 => June 4
This is presumably the massacre of students in Tiannamen Square (sorry not
sure about the spelling), in Bejing/Peking.
There is a boot virus, loosely based on Stoned, which includes the message
"Bloody! Jun.4, 1989".  The usual names I have seen are "Bloody" and "June 4".

> I found there a "Kill" progr, and apparentlyI have cleaned my stuff off.
> However bere transferring material form my travelling kit to my computer
> in Guelph I would like to know if any of you know anything about this
> virus and if it could be lingering still somewhere:
> a. I was using a palmtop (Sharp 3100) with built in software: could the
> virus have entered such software ?
> ..

As a boot sector virus it is unlikely to have been transferred to a palmtop,
unless user has disk image files (eg using Teledisk).  I would expect all
a-v software to detect "Bloody"/"June 4", as F-PROT is one of the more
comprehensive scanners you could use it for reassurance.

Hope this helps,
Anthony Naggs
Software/Electronics Engineer                   P O Box 1080, Peacehaven
(and virus researcher)                          East Sussex  BN10 8PZ
Phone: +44 273 589701                           Great Britain
Email: (c/o Univ of Brighton) [email protected]  or  [email protected]

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

Date:    Wed, 09 Sep 92 23:55:39 -0400
>From:    [email protected] (A. Padgett Peterson)
Subject: Re: NetWare and viruses - some new results (PC)

>From:    [email protected] (Vesselin Bontchev)
>
>By "exhaustive test" he means exhaustive test. He has generated 256
>directories will all possible combinations of access rights and has
>tried to infect the files in them.

In fact, I have found that only a very small number of the 256
possible combinations prevent possible infection (believe it is 24 but
CREATE is confusing the issue. If you have CREATE you can infect a
directory unless you also have READ in which case you must also have
WRITE unless you are a MacIntosh...). Please note that I include those
cases that a virus *could* be written to exploit (such as MODIFY and
where a file is known to be in a directory that cannot be searched).

>> 4. A virus which has Read, Write and File Scan rights, can infect
>> target files.  Therfore careful consideration should be given to use
>> of the Write right.

Unfortunately, many users (and some applications) become very unhappy
if they do not have WRITE right in their own directories. This was the
problem I had with one LAN last year, the custom MAIL facility
demanded WRITE right to itself. JERUSALEM spread like mad.

>And, if the user is given the right to modify the rights, the virus
>could do so as well and to set the Write right, even if it is not
>initially set. A more exact configuration that prevents virus
>infection can be found in Dr. Cohen's paper.

Specifically, you must have NOT SUPERVISOR AND NOT WRITE AND NOT
MODIFY AND (NOT CREATE OR READ). (Boolean math in ASCII is difficult).

>Correct. What Dr. Cohen has actually observed is that the "default"
>configurations and even those configurations that are usually
>considered "secure" do not actually prevent a virus attack. It -IS-
>possible to set the right in a way that will stop viruses, it is just
>not easy to figure out how exactly.

Not really difficult once the rules of RIGHTS and INHERITANCE are
understood, see above.

>I encourage you to read Dr. Cohen's paper. Unfortunately, he refused
>to make it available in electronical form, so you should refer to the
>proceedings of the 2nd Virus Bulletin Conference.

Unfortunately typical. I actually held his book in my hand for nearly 15
seconds before it was snatched away.

>His basic theory is that it is very difficult to figure out how to
>manage the NetWare rights in a way that will stop virus attacks.

Not difficult at all, just what is required is unlikely to be palatable
to users. One of the difficulties is that unlike UNIX or a Mainframe
where a process may take on rights denied to the user as a function of
the owner (see ROOT), under PC Netware, a user must have all rights
required by a process. Hence to pass mail, EVERYONE *must* have CREATE
right to all MAIL subdirectories (see boolean above).

>P.S. I don't have the paper handy right now. We (the VTC-Hamburg) are
>planning to repeat the tests, in order to verify the results.
>Unfortunately, we can repeat only the Novell Netware tests (since we
>don't have a Unix-based DOS server) and only for version 2.15. :-(

Our testing has been done so far on version 3.11 (386 server) - there is
a Sun server but the owner is not stupid enough to let me play with it - yet.

I hope in the near future to convert my den closet to Novell so that some
nastier testing can be done.

Incidently, we have also been testing both Intel's LANPROTECT and
McAfee's NETSHIELD and I would consider both to be a good version 1.0
but IMHO some cleaning up needs to be done (example: client FROG is
infected with SUNDAY. On logging into server SUNDAY tries to infect
LOGIN.EXE but lacks WRITE right {I love that}. No alarm is raised at
the failed attempt (default). On reaching his home directory SUNDAY
infects MAPMEM on request. Both products then notify FROG that MAPMEM
is infected and deny access. Neither warns FROG that *he* may be the
source. FROG then calls SUPERVISOR over to report that there is an
infected file on the server and...)

Again IMHO, what is really required is a layered defense (where have we
heard that before ?) 1) Integrity TSR active on CLIENT to ensure cleanliness
                    2) Check of CLIENT on login to verify cleanliness
                    3) Monitor for attempted illegal activity by CLIENT
                    4) Scanner for legal file transfers and on exceptions
                       reported by 1-3.

NETSHIELD and LANPROTECT accomplish item 4 only. Of course it could be
said that other products exist for the other three items e.g. McAfee's
VSHIELD for item 1 and Intel's LPSCAN for item 2 but I like one-stop
approachs. Of course IMHO both products are good enough that they are
worth a little prodding to make them great.

                               Warmly,
                                       Padgett

BTW thanks to all of those who responded, I have enough LAN adapter cards now.

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

Date:    Thu, 10 Sep 92 04:26:25 -0400
>From:    [email protected]
Subject: Re: Tan an Door virus?!?! (PC)

The square in Beijing (formerly known as Peking) in China where the
massacre occured, is correctly called 'Tien An Men Square', because it
is by the 'Tien An Men' = "Heaven(ly) Peace Gate". (Do not confuse it
with the Indian cookery word 'tandoori'.) Your informant seems to have
part-translated the name. Is this virus the virus usually known as
'Beijing' or 'Bloody'?, which contains matter referring to that event.

> Date:    Tue, 08 Sep 92 11:08:48 -0400
> From:    Paul Bradshaw <[email protected]>
> Subject: Tan An Door virus?!?! (PC)

> The following recently appeared on our local virus conference here at the
> University of Guelph. I've never heard of the tan an door virus, or the 64
> virus as the gentleman refers to it and would like to hear from any of you
> who have.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Title: Tan An Door Virus
> Recently in China I cought the 64 VIRUS which apparently was related to the
> incident of June 4 atthe Square of Tan An Door in Peijiang (Bejing ?). I
> found there a "Kill" progr, and apparentlyI have cleaned my stuff off.
> However bere transferring material form my travelling kit to my computer in
> Guelph I would like to know if any of you know anything about this virus
> and if it could be lingering still somewhere: a. I was using a palmtop
> (Sharp 3100) with built in software: could the virus have entered such
> software ? ..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> I would like to help the poor guy out, but I haven't the faintest idea what
> this virus's commonly accepted name would be. Thanks all, Paul Bradshaw
> [email protected]

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

Date:    Thu, 10 Sep 92 05:14:18 -0400
>From:    G J Scobie <[email protected]>
Subject: Netware Rights again (PC)

I have been reading with interest the discussions concerning Netware
Rights and thought I would throw my own observations into the ring :-)

Certainly on page 227 on the Concepts manual for netware 3.11 it states:

"Attribute security overrides rights granted with trustee assignments
and can prevent tasks that effective rights would allow".

So what does this mean in reality? Let us suppose I have all rights in a
directory and to the files contained there. If I flag a file as
read-only, netware 3.11 automatically adds the delete-inhibit and the
rename-inhibit attribute to this file. Now although I have the erase
permission any attempt to delete this file will give me an access denied
message.

Now futher down page 227 of the concepts manual it states that:

"If users have the Modify right for the directory or the file, they can
change the attributes and complete any task allowed with their effective
rights."

Fair enough. I have the modify right, so what happens if I just remove
the delete-inhibit attribute? Although the file is still flagged as
read-only, I have erase permission so I can delete it.

This is explained again on pages 230-231. This situation holds for
supervisors as well. By default the system files are installed with the
delete-inhibit attribute set, in order to prevent supervisors from
accidentally deleting files.

So where does this leave us? Certainly attribute security in this
instance, overrides rights granted with trustee assignments, and is
explained quite clearly in the manuals. Perhaps confusion has arisen
regarding the read-only attribute in netware and that under DOS.

As for viruses, I feel that we should all assume that if a user has
certain rights then a virus will have those rights as well. Infection of
files on a server is an issue notably in users home directories, and
anyother area that they have more than read/filescan permission.
Supervisors - if they are at all worried - should cold-boot from a known
clean source before commencing work with supervisor status.

It worries me that perhaps too much has been made of the "default
configuration" of netware servers. I can't think of any system which
comes pre-set for maximum security. It is not a specifically novell
problem.

To conclude, I work on the basis that the security as far as viruses are
concerned are only as good as the rights users have to their areas of
the servers disks. If a virus can infect my applications volume where
everyone has only read and filescan permission set as a trustee
assignment then I would appreciate being told about it as soon as
possible.

Thanks for all the great work on this board. Its appreciated more than I
can say.

Cheers

Garry Scobie
Senior Computing Officer
EUCS
Edinburgh University

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

Date:    Thu, 10 Sep 92 06:50:58 -0400
>From:    J|rgen Olsen <[email protected]>
Subject: F-PROT 2.05 - minor problem detected. (PC)

Having brought home my personal copy of version 2.05 (collected from
Fredric i Edinburgh, I used the SAVE feature after doing a scan with
the heuristics option (lots of 'semi-false' positives but correctly
identified as being so).

The result : Funny things happened - system hang (5) - funny
Characters on screen (1) - garbled report (misc.characters replaced
with others) (2).  The above numbers refers to 8 test on 3 machines.

I seems that saving of larger files results in
   a) no save - with or without hang.
   b) no save - with an entry of length ZERO (0).

By the was if yopu only write a program name when prompted the file
(if it is a small one) will be placed in the root of the last logical
disk on your system.

In these days with a lot of cheap RAM around this will often be a
RAMDISK on many (non-networked) machines. Maybe an other saving
strategy should be considered!

The whole thing is a minor nuissance - when you know of it! But
distributing version 2.05 to 1600 users might give us a feedback we
should like to be without.

As no one has reported the problem - few people seems to use the SAVE
feature!

J Olsen
DOU, Odense DK

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

Date:    10 Sep 92 10:47:37 +0000
>From:    [email protected] (Vesselin Bontchev)
Subject: Re: F-prot false alarm? (PC)

[email protected] writes:

> Just obtained F-prot 2.05 from simtel. Unpacked it and did a secure
> scan.  To my surprise backup.exe (from dos 5.0) was reported as being
> infected with the Stanco virus. The file was packed with pklite. I

Hmm, it's a nasty false positive... For the reasons, see below. I
suggest that you send a private message to Frisk about that, since
he's now on holidays and may miss your article...

I didn't know that BACKUP.EXE from DOS 5.0 is PKLite'd... (I am using
DR-DOS 6.0.) DR-DOS -does- have most of its utilities in a PKLite'd
form, but I thought that Microsoft/IBM don't do that...

> Looked the virus up in the info table of f-prot and it says the virus
> replicates only in compressed form??! Also Virstop didn't stop
> backup.exe from running.  I think this is a false alarm (or I hope it
> is).

> Does anyone has more information regarding the Stanco virus?

It is a virus written in Turbo Pascal and compressed with PKLite. Was
first detected in Genoa, Italy. The size is about 7500 bytes. It is** PGP publi
c key available on request. **   Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected]    D-2000 Hamburg 54, Germany

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

Date:    10 Sep 92 08:55:06 -0500
>From:    [email protected]
Subject: Re: New files on eugene and beach (PC)

>From:    John Perry <[email protected]>
>
>Hello Everyone!
>
>Better late than never I always say! I've finally had a chance to sit
>down and update the anti-viral archives on eugene and beach. Please
>make note of the following additions. If there is a problem or
>question, please feel free to contact me at [email protected].
>
>eugene.utmb.edu
>vsig9207.zip

vsig9208.zip is on risc.ua.edu and oak.oakland.edu.
- ----------
James Ford - Consultant II, Seebeck Computer Center
            [email protected], [email protected]
            The University of Alabama (in Tuscaloosa, Alabama)

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

Date:    Thu, 10 Sep 92 11:16:31 -0400
>From:    "Chip Seymour, Information Resources" <[email protected]>
Subject: Problem with Vshield 5.1B95 (PC)

I believe I am having a problem with VSHIELD. It loads ok, but when I
do a MEM/C, it produces "blem wit" as the program name.  Anybody else
come across this?  (v5.1B95)

=============================================================================
Conventional Memory :

 Name                Size in Decimal       Size in Hex
- -------------      ---------------------   -------------
 MSDOS              19472      ( 19.0K)       4C10
 SETVER               544      (  0.5K)        220
 ANSI                4192      (  4.1K)       1060
 HIMEM               1184      (  1.2K)        4A0
 SMARTDRV           18592      ( 18.2K)       48A0
 RAMDRIVE            1184      (  1.2K)        4A0
 ATDOSXL             9520      (  9.3K)       2530
 MOUSE              14816      ( 14.5K)       39E0
 ETHDEV             30400      ( 29.7K)       76C0
 TCPIP              16480      ( 16.1K)       4060
 COMMAND             4416      (  4.3K)       1140
 3C503               3936      (  3.8K)        F60
 DOSKEY              4128      (  4.0K)       1020
 IPX                16960      ( 16.6K)       4240
 NET5               42112      ( 41.1K)       A480
 blem wit           38832      ( 37.9K)       97B0   <---------
 FREE                  64      (  0.1K)         40
 FREE                 144      (  0.1K)         90
 FREE              426944      (416.9K)      683C0

Total  FREE :       427152      (417.1K)

Total bytes available to programs :                           427152   (417.1K)
Largest executable program size :                             426688   (416.7K)

  5242880 bytes total contiguous extended memory
        0 bytes available contiguous extended memory
  2293760 bytes available XMS memory
          MS-DOS resident in High Memory Area
=============================================================================
Chip Seymour
ComputerVision    [email protected]
Bedford, MA
=============================================================================

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

Date:    Thu, 10 Sep 92 12:47:41 -0400
>From:    [email protected] (A. Padgett Peterson)
Subject: Netware (PC)

In my last posting, I accidently referred to the MODIFY right when the
reference should have been to the ACCESS right in the boolean
equation.  MODIFY is only of importance if certain non-default
attributes (e.g.are set.  ReadOnly are set.

                                               Padgett

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

Date:    10 Sep 92 17:45:57 +0000
>From:    [email protected] (Jesus Miguel Garcia Rodriguez)
Subject: NAVSCAN (PC)

Where can i get NAVSCAN?  or When its gonna be out?

Thanx.
/\/\otley.

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

Date:    Thu, 10 Sep 92 20:01:45 -0400
>From:    [email protected] (A. Padgett Peterson)
Subject: Re: NetWare and viruses - some new results (PC)

>From:    [email protected] (Vesselin Bontchev)

Note: my  comments refer  to Netware 3.11 which Fred is using also but
      is different from what Vessilin has at the VTC in Hamburg.

>[email protected] (Kevin Hemsley) writes:

>> can access and what the user is allowed to do with them.  Rights
>> Security supersedes attribute security, in that a user must first be
>> given access to a directory, subdirectory or file before attributes
>> can be defined for each.

Vesselin repondeth:

>Correct. It is indeed so. Unfortunately, the manual says exactly the
>opposite.

I  agree with the conclusion that the structure can be confusing  *however*
IMHO  the  manual  (Concepts page 8) is correct.  Attributes  do  supersede
Rights  (more  correctly  *complement*). If the ReadOnly  bit  is  set   an
attribute  must  be  changed  before a file can  be  altered,  deleted,  or
renamed irreguardless of what rights a user has (including Supervisor).

If you are considering action based on what must be granted to gain access,
then the  rights  must  *precede* any test of the  attributes  but  do  not
*supersede*  the  attributes. Rights (Supervisor, Modify) can  be  used  to
change attributes but not to bypass them.

One  of  the  things  I feel to have been fortunate  in  my  education  was
exposure  to  such  things  as Set  Theory,  Boolean  Algebra,  and  Linear
Programming  at a tender age, courses that I fear are rarely taught  to  CS
majors  nowadays. The concepts of rights and attributes are best  expressed
as Boolean relationships as is attempted to be rendered into ASCII below:

Possibly  the best way to look at the difference is that RIGHTS state  what
the user is permitted to do to a file or a directory. ATTRIBUTES state what
is  *not*  permitted  to  be done to a file  or  directory:  RIGHTS  allow,
ATTRIBUTES  disallow.  RIGHTS refer to the user, ATTRIBUTES  refer  to  the
object  (oops  8*).  In  Boolean  terms  you  must  be  allowed  and  *not*
disallowed.

Thus for a particular file (say MAPMEM.COM), the user rights NOT SUPERVISOR
AND  NOT  ACCESS  AND NOT MODIFY ANDed with  the  file  attribute  READONLY
*should*  protect  MAPMEM.COM  from direct infection  (says  nothing  about
companion or path viruses, just that this particular copy of MAPMEM.COM  is
protected).

In contrast, while contextually NOT SUPERVISOR AND NOT ACCESS AND NOT WRITE
has  the same protection for MAPMEM.COM, the protection is extended to  all
files  in  the directory. In short attributes protect a file  or  directory
from  everybody while a lack of rights protects the file or directory  from
the user.

Generally  though, rights have more power than attribute since  either  the
SUPERVISOR  or  MODIFY right can be used to change any  attribute  *except*
one: once the EXECUTEONLY attribute is set, it cannot be changed, the  file
can  only be deleted and restored from a fresh copy. This is  obviously  an
attempt  by  Novell to protect an executable even from an  infected  client
with SUPERVISOR right.

However,  despite  such powerful macros as FLAG RO *.* /S,  attributes  are
falling out of use for two reasons:

1)   Unlike  RIGHTS which are enforced at the server level, attributes  are
     enforced by the client shell (hence the PC - MacIntosh difference) and
     may be overridden by directed client software (some viruses do already
     - I have some testing planned).

2)   As  noted by Dr. Cohen, the logic can be puzzling particularly if  all
     that  one has to go on is the CONCEPTS volume and  conventional  (even
     UNIX 8*) data protection experience. Ignorance is curable.

Given  all of the above, once the proper logical understanding is  made  of
rights  and  attributes,  I  see  no  difficulty  in  understanding   their
implications,  not do I find any problem with the documentation other  than
it  is  more  of an encyclopedia than a tutorial. In other  words,  if  you
already know the answer, it is useful. If not, hire a CNE. (or CNA now).

More importantly to the non-technical manager who has been receiving  these
contradictory  reports  via  Virus-L  (have had a  few  calls  already),  a
*properly*  set-up  Novell  LAN not IMHO a flawed system that  is  an  open
invitation  to  viruses.  In  fact  it is  less  likely  to  experience  an
uncontrolled virus infection than a stand-alone PC even though the  Netware
security is not directed at protection from malicious software.

Again  IMHO LANs that are at risk (that is *all* that are  not  single-user
like  mine  8*) need a properly layered mix of Novell,  third  party  NLMs,
exception reporting, and TSRs to achieve a high degree of confidence but it
*can* be done.

Further,  being in a nasty mood, I'll reiterate that IMNSHO *only*  client-
server  systems supporing login scripting such as Netware can  be  properly
protected  from infected clients. Peer-peer systems that do not  are  virus
havens.

                                       Warmly,

                                               Padgett

ps  don't  forget  that the above comments refer to  the  current  product,
     Netware 3.11 & may not apply to older/other versions

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

Date:    Thu, 10 Sep 92 21:01:23 -0400
>From:    Anthony Naggs <[email protected]>
Subject: Re: VACSINA Information Wanted (PC)

Remembering that a well known story teller, :-), gave me this advice:
> Rule 0. Read before arguing. :-)

I believe I have read, so here goes...

Vesselin Bontchev, <[email protected]>, wrote:
> [email protected] (Anthony Naggs) writes:
>
> > > Is it important that one utility recognised CHKDSK while the other did
>     not?
>
> > Yes, 'EXE' files modified in this way may be corrupted and either fail to
                                         ***

Reading test; do you see the word 'may' in my previous answer?  In the
particular incident discussed there is no problem, as CHKDSK functions
normally in this state.  However I was answering the question of
whether scanners should detect such files.

> > work or work incorrectly.  This includes a number of programs that
> > use overlays or include configuration information in the executable file.
>
> True in general, but this particular virus (Vacsina.05) does not
> infect files with internal overlays or trailing configuration info.
> So, in this particular case there is no danger.

No.  No.  No.  Even with the care that Vacsina takes there can still be
problems.  For instance programs, as discussed here recently, that check
themselves will notice such a change and refuse to run.  If the detection
utility misses this file in the list of those affected, then the user will
suspect that s/he is also suffering from a new virus.  This is likely to
cause some anxiety!

I hope this is clear, and I shall save my ration for other topics.

Anthony Naggs
Software/Electronics Engineer                   P O Box 1080, Peacehaven
(and virus researcher)                          East Sussex  BN10 8PZ
Phone: +44 273 589701                           Great Britain
Email: (c/o Univ of Brighton) [email protected]  or  [email protected]

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

Date:    07 Sep 92 19:39:57 +0000
>From:    [email protected] (Paul Ducklin)
Subject: Re: F-Prot & SuperStor (PC)

Thus spake [email protected]:
>Second: IBM PC question.
>Can anyone advise me whether there is a virus that modifies the
>seconds field in a files time value to 62. I seem to recall that there
>is a virus which does this.

Plenty of viruses use this trick. Vienna was probably the first -- and
the source went and got itself published in a book \end{flame}, with
the result that it became a popular technique.

Or, of course, you might have a program that's been "innoculated"
against various viruses, including those which avoid infection if
they see a second stamp of 62. [Incidentally, M*crosoft allocated
5 bits for "seconds", so a DOS filestamp has a 2-second granularity;
62 seconds are actually 31 M*crosoft-double-seconds].

Try as decent virus scanner [after a clean boot, of course] if you
want to identify what it is.

- --

- --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--
Paul Ducklin                                           [email protected]

   CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa

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

Date:    07 Sep 92 19:32:05 +0000
>From:    [email protected] (Paul Ducklin)
Subject: Re: F-PROT reports Bugsres 3 Jokes program? (PC)

Thus spake dana%[email protected] (Dana E. Keil):
>I just obtained F-PROT. Running a scan with it reports that a file
>named bugres.com is infected with a virus named "bugsres 3 jokes
>program". I can find no mention of this virus anywhere in F-PROT
>documentation (nor elsewhere). Can anyone enlighten me about it?

The bugsres program I've seen is a non-viral TSR which waits for
a hotkey and then starts up a bunch of text-mode "insects" which
run around, chomping up the screen. A "joke", and not a virus.
Of course, the problem with "jokes" is that jokers tend to
encapsulate them in replicative engines and to let them go...

Why keep software around if you don't know its function, anyway?
Seems to be a waste of disc space to me - and a recipe for disaster.

- --

- --<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--
Paul Ducklin                                           [email protected]

   CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa

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

Date:    Fri, 11 Sep 92 07:24:17 +0000
>From:    [email protected] (Matthew Campbell 'The Fire Fox')
Subject: Now I know I have something. (PC)

VIRSTOP was installed as a device driver in Config.Sys right after
Himem.Sys

Later I tried installing VIRSTOP from the command line and it said:

>VIRSTOP cannot be installed
>This may be caused by an active virus or an incompatible DOS
>
>C:\VIRUS> f-prot.exe
>Program infected with the [= ] Virus.
>File access terminated. (A couple weird characters)(Control-Z) and a
>                        halted system.

I had just unzipped fp-205.zip from a clean, write-protected floppy
disk; however, I didn't happen to boot with one.  Has this ever
happened to anyone else before?  After killing the power for about a
minute, I rebooted with a clean, write-protected floppy disk and
scaned the drive with a different disk on which the scanner files were
already expanded, (Not Zipped).  I also scanned the other disks that
came in contact, but no viruses were detected.  I got my F-PROT from
wuarchive.  Is F-PROT supposed to have -AV with the files when
unzipped?  Mine doesn't.

SCANNING RESULTS:

Scanner used: F-PROT v205
Infected:     0
Suspicious:   12  (Mostly .ini and .cnf files)
Disinfected:  0
Scanning:     Hard Disks
Method:       Heuristics
Scanning:     All files
Message:      This is either a corrupted program or one which contains
             instructions wich do not exist on all 80x86 processors.
             It will crash on some machines.

  -- text files were noted as suspicious such as NEW.205, SCAN.DOC,
     LANGUAGE.DOC, CONFIG.SYS, AUTOEXEC.BAT, and all scan.crc files.
  (scan.crc files are files made with McAfee's scanv95b.zip scanner.)
  (/af scan.crc)

Scanner used: SCAN 8.7B95 McAfee
Options:      C: /a /m /chkhi
Infected:     0
Suspicious:   0

A disk editor revealed extra garbage added to the ends of the
suspicious files as named by F-PROT v205.  The extra stuff held two
sectors or less.  The file names EMM386.EXE and SMARTDRV.EXE were
added to the end of LANGUAGE.DOC which were two files that the
computer uses in the boot up.  You should see the end of the
Config.Sys.... What a mess.  Some hex codes include:

89 97 88 89 99 A8 89 FF CF 89 9D E8 89 9F 08 8A
A1 28 8A A3 48 8A A5 68 8A A7 88 8A A9 A8 8A AB
C8 8A AD E8 8A AF 08 8B B1 28 8B B3 48 8B B5 68
8B B7 88 8B B9 A8 8B BB C8 8B BD E8 8B BF 08 8C
C1 28 8C C3 48 8C C5 68 8C C7 88 8C C9 A8 8C CB
C8 8C CD E8 8C FF FF FF D1 28 8D D3 48 8D D5 68
8D D7 88 8D D9 A8 8D DB C8 8D DD E8 8D DF 08 8E
E1 28 8E E3 48 8E E5 68 8E E7 88 8E E9 F8 FF EB
F8 FF ED E8 8E EF 08 8F F1 28 8F F3 48 8F F5 68
8F F7 88 8F F9 A8 8F FB C8 8F FD E8 8F FF 08 90
01 29 90 03 49 90 05 69 90 FF 0F

For the next two sectors it had something that looked like a data file
containing names of viruses like: Violator, Stoned, Vienna, Hydra, and
had names of the current scanners, characteristics of viruses, the
months of the year, and some names of some countries.

What should I do?

- --
Matthew Campbell     'The Fire Fox'
Internet:  [email protected]     [email protected]
          Ugcsmc0084%[email protected]
A thought to remember: "The only way to God is through his son Jesus Christ."

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

Date:    11 Sep 92 08:34:04 +0000
>From:    [email protected] (Vesselin Bontchev)
Subject: Re: A new virus????? HELP! (PC)

[email protected] (Cam Scholl) writes:

> Anyways, here's what is happening.  Every once in a while, my system
> will try to access a file, only to find out that somehow, it has been
> damaged!  This has happened to Windows 3.1 program manager groups,

Could be done by a virus, of course, but it doesn't sound like a virus
problem to me... Most people seem to think that destruction of
information is the most indicative symptom of a virus infected. In
fact, the most important property of the viruses is their ability to
spread. Only some of them intentionally cause a noticeable corruption
of data. Remember, the main goal of the virus is to spread. And, if it
destroys data in a noticeable way, you are likely to notice it and to
remove it, therefore it will not be able to spread further...

> Shortly thereafter, I ran into the same problem...  After much
> investigation, I have found that the virus seems to only attack files
> with their archive bit set, meaning they've been changed since the

This is quite indicative. Most viruses are clever enough not to modify
any file attributes. What you are actually observing should be
interpreted in the opposite way - not that something is modifying your
files with archive bit set, but that something is modifying your
files in a standard way (via the documented MS-DOS functions), which
sets the archive bit.

My guess is that you don't have a virus. Probably some kind of faulty
application.

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 public key available on request. **   Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected]    D-2000 Hamburg 54, Germany

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

Date:    11 Sep 92 08:42:52 +0000
>From:    [email protected] (Vesselin Bontchev)
Subject: Re: Auto-detecting Virus (PC)

[email protected] (Alexander Ofek) writes:

> Your approach will fail to detect a stealth virus like 1963 or dir2.
> To be on the safe side you will have to read the directory using absolute rea
d
> (int 13h) and follow the FAT chains yourself.

Which will fail to detect advance stealth viruses like Int13, which
are stealthy at sector access level. Using INT 13h to read the file
will not detect Dir_II either, since this virus subverts the block
device driver requests...

> Of course it might be useful to
> check whether the interrupt vectot of int 13h still points to the BIOS area.

Unfortunately, since DOS 3.20 the interrupt vector for INT 13h never
points to the BIOS area (except at boot time), since DOS intercepts it
itself...

There are other possible anti-stealth techniques that could be used,
like scanning the ROM space for the hard disk controller program and
calling it directly, but neither of these tricks is reliable and/or
compatible with all kinds of systems... Just as an example, consider a
disk, compressed with Stacker... How are you going to access the files
on it "at a low level"?

The -only- secure technique against the stealth viruses is to use the
"magic object" - to cold boot from a write-protected non-infected
system diskette. Unfortunately, this method of operation is considered
too inconvenient by most users. Furthermore, it can be used only for
off-line integrity checkers, and what the original poster proposed was
an integrity module, contained in the executable file. In this case,
there's no way to stop the stealth viruses from fooling the integrity
module.

> Use any CRC check with an UNUSUAL (i.e. rarely used) polinomial.

More exactly, use a CRC with a -different- polynomial on each
particular installation (be it a computer or a program).

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 public key available on request. **   Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected]    D-2000 Hamburg 54, Germany

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

Date:    Wed, 09 Sep 92 21:53:11 -0500
>From:    Gene Spafford <[email protected]>
Subject: Re: Looking for references (UNIX)

See the postscript files on ftp.cs.purdue.edu in pub/spaf/security
In particular, see IWorm and IWorm2

Also, here's some info on Robert Morris that many people ask for:

Robert T. Morris, the author of the Internet Worm program, was
convicted of a Federal felony in the case.  The law involved was 18
USC 1030, the Computer Crime and Abuse Actof 1986.  He was found
guilty in February of 1990 in US District Court in Syracuse, NY.

In May of 1990, he was sentenced -- outside of Federal guidelines --
to 3 years of probation, 400 hours of community service, and $10,000
in fines plus probation costs.  His lawyers appealed the conviction
to the Circuit Court of Appeals, and the conviction was upheld.  His
lawyers then appealed to the Supreme Court, but the Court declined to
hear the case -- leaving the conviction intact.

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

Date:    Thu, 10 Sep 92 15:37:47 +0000
>From:    [email protected] (Jerry Natowitz)
Subject: Virus scan for AIX 3.2? (UNIX)

I have never heard of a Unix based virus scanner, but I have been
asked to investigate virus scanning of software built on, and running
on, an RS6000 running AIX 3.2.

Any leads, freeware or commercialware, would be appreciated.
- --
    Jerry Natowitz
    Guest user on:
ARPA [email protected]
UUCP {ima,harvard,rayssd,linus,m2c}!spdcc!jin

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

Date:    Thu, 10 Sep 92 02:54:38 -0400
>From:    Christian Burger <[email protected]>
Subject: Re: self-checking programs

In response to the posting of D. Beauregard on self-checking programs
and to several comments thereon:

You should have a look at the ``Stealth Bomber'' package by Kevin
Dean.  It implements a crc self-check plus additional anti-virus
features for borland turbo c or pascal programs. The package uses a
very sophisticated way to circumvent the problem that the crc itself
is part of the stream to calculate the crc from, patching the
executable after compilation. This package will probably not protect
against all stealth viruses but it will certainly provide a good
protection against the most common viruses. The stealth bomber package
is freely available via anonymous ftp from any simtel archive mirror
as /msdos/trojan-pro/stealth.zip.  I would be interested in comments
of the virus gurus on this package.

Christian Burger, [email protected]

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

Date:    Fri, 11 Sep 92 03:47:13 -0400
>From:    [email protected]
Subject: Self-modifying programs

Re self-modifying programs confusing virus scanners: before PC's were around,
my university had a mainframe that had an Algol60 compiler that compiled
(subroutines that had parametric subroutines) thus, e.g.:-
   real procedure integrate(fn,q,w,e,r,t); real procedure fn; real q,w,e,r,t;
   begin; .... x[2]=fn(q+w); ...... z=fn(t); ..... x[4]=fn(e+r); ..... end;
The compiled version of procedure 'integrate' started with code which wrote
a copy of the (entry address of whatever 'fn' was in that call) into the code
of 'integrate' wherever it calls 'fn'. I don't know if there are any compilers
around nowadays that do that sort of thing.

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

Date:    Wed, 09 Sep 92 22:32:29 -0400
>From:    Anthony Naggs <[email protected]>
Subject: Re: Comp Virus Conferences ... THE BEST CONFERENCE THIS YEAR!

Francesco Dalla Libera, <[email protected]>, asked:
> Yes, maybe I'm too lazy or I do not remember very well, but there is a
> list of the most important Computer Virus Scientific Conferences for
> the next year [1993, off course] ?

A couple I know of next year:

6th International Computer Virus & Security Conference
   March 11th-12th 1993, New York City, NY USA
   Dick Lefkon posted a call for papers here a little while back.

3rd Virus Bulletin Conference
   probably in September again

However the best one to attend, -subtle hint-, this year is still to come:

The 3rd annual EICAR Conference
   (EICAR - European Institute for Computer Anti-Virus Research)
   December 7th-9th, Munich Germany

   Quick outline:
   Monday 7th is an introductory day.
   Tuesday 8th has an opening talk, and splits into technical and
               management tracks.
   Wednesday 9th continues with technical and management tracks,
               which join in the afternoon for a panel discussion.
   Tuesday and Wednesday will have papers in English and German with
               translation provided.

   If you have not sent your draft papers to Christoph, the deadline is
   Friday September 11!  Final arrangements and full details of the
   programme will be posted here soon.

   Email for info to:  Christoph Fischer [email protected]
               or (UK) Anthony Naggs     [email protected]

Anthony Naggs
Software/Electronics Engineer                   P O Box 1080, Peacehaven
(and virus researcher)                          East Sussex  BN10 8PZ
Phone: +44 273 589701                           Great Britain
Email: (c/o Univ of Brighton) [email protected]  or  [email protected]

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

End of VIRUS-L Digest [Volume 5 Issue 151]
******************************************



Downloaded From P-80 International Information Systems 304-744-2253

You are viewing proxied material from infinitelyremote.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.