From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Newsgroups: comp.virus
Subject: Re: "New trends and other stuff"
Date: 23 Sep 92 07:59:15 GMT

seborg@csrc.ncsl.nist.gov (Brian Seborg) writes:

> some dismay.  Regarding the "new trend" to allow your computer to boot
> off of the C: drive rather than the a: drive, this is not new.  Hasn't
> anyone heard of a Zenith 248?  The military only has about 650,000 of
> them.  This boot redirection has been re-definable in cmos for
> some-time.  We're talking pre 1988 here.

The "new" in the trend is that nowadays more and more BIOS producers
are providing this feature.

> Regarding Cohen's paper, I guess I am somewhat tired of hearing about
> a paper that I do not have a copy of and perhaps that is making me
> somewhat testy, but let's be serious about network security.  I hope

The paper is in the proceedings of the 2nd Virus Bulletin conference.
You can order the proceedings from Virus Bulletin.

> we are not going to have to find out that networks can be set up in an
> un-secure manner.  What a surprise!  I work in a Banyan environment

The point in Cohen's paper is that the "obvious" way to set a Novell
LAN is insecure, not that it is not possible to set it up in a secure
way, or that it can be set up in an insecure manner. I have quoted the
secure settings listed in his paper in one of my previous messages.
Take a look at them, then take a look at the LANs you have seen. Are
they set up in this (secure) way? Till now only Padgett has succeeded
to figure out himself what the secure settings are... The average
supervisor usually makes a mistake or two, exactly because the secure
settings are not obvious. And the equations that I quoted concern only
the effective file rights. If you try to take into account all
inheritance masks, the task becomes even more difficult.

> to a nation-wide WAN, I have some experience here.  I understand the
> need to quantify security policy, but taking common practices and
> reducing them to set notation for the sake of publishing a paper seems
> to do nothing to advance the field.

I disagree. The paper clearly lists what the secure settings are,
mentioning why any other settings can be bypassed. It emphasizes that
the ExecuteOnly attribute should not be trusted, because it can be
easily bypassed - and do you know how many Novell LAN users rely on it
for protection? There are many other interesting things in the paper.
The only problem is that it concerns mainly version 3.x of NetWare
(and the Unix NFS servers, but this is another story). In our tests at
the VTC-Hamburg we have found that version 2.15 is -completely-
different and the equations for the secure settings in it are also
very different from the ones listed in Dr. Cohen's paper. I'll
summarize the results of our tests in an article, which I hope to post
here soon.

> 1) Set the access rights for applications drives (file-services) to
> read only for all users including administrators.  Administrators can
> always change the permissions back temporarily when making updates or
> changes, but will be protected from inadvertantly infecting the system
> in general.

Unfortunately, under Novell NetWare and Unix, the person with
supervisor (root) privileges can bypass the protection, without having
to modify the permissions...

> Some programs require users to have modification rights to
> applications directories.  My experience suggests that most programs
> of this sort can be set up so that users are given modify rights to
> some files which are put in a seperate directory, and the application
> itself can still be write-protected.  This is true for Paradox for

It might be true for Paradox, but it isn't for dozens of other
applications... But I agree with you that such applications have to be
avoided.

> 2) If possible, do away with all file services where multiple user's
> have write-access (except in small groups).  "Bit Bucket" file
> services where everyone has write access are good places for Trojan
> Horse programs, companion, and path companion viruses (or standard
> trojans), and, in addition, are hard to manage since determining
> ownership is a problem.  If you must have these type of file services,
> limit the number of users (i.e. fragment them into smaller chunks, by
> functional working group for example), don't allow any .bat, .com,
> .exe, files to reside in these directories.  Any applications,
> including batch files, should reside in write-protected areas.

As I have described in my paper (available by anonymous ftp), there
exists a form of virus attack, involving PATH-companions and at least
one writable directory - be it the user's home directory on the
server, or one of the local workstation's directories. The attack is
not specific to Novell and allows a virus to bypass any protections
and to make all protected applications to look and behave as if they
are infected. Fortunately, the infection does not spread between
users.

> Also, make sure that user's path statements do not contain directories
> where multiple people have write-access.  This is not only
> unnecessary, but dangerous as well.

Problem is, the PATH variable cannot be protected at all, due to the
lack of memory protection in Messy-DOS...

The rest of your suggestions are very sound and should be carefully
followed by all LAN users, regardless of the LAN type.

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.0 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