From: Vi...@thebeach.u-net.com (Vijay Bhakta)
Subject: Security flaw with Office97
Date: 1997/07/16
Message-ID: <33cc7dd4.5378994@news.u-net.com>#1/1
X-Deja-AN: 257167724
Organization: U-NET Ltd
Reply-To: vi...@thebeach.u-net.com
Newsgroups: comp.os.ms-windows.nt.admin.security


Hi,

We have come across what seems to be a serious flaw with the NTFS
security required by Office97.

We have set our NT 4.0 workstations with the tightend security as
shown in the resource kit as we dont want the user to have write
access to any part of the hard drive (with the exception of c:\temp).

We started getting a few funnies with office, which we couldnt work
out, looking thru Technet revealed a worrying article - Q169387
"OFF97: Security Requirements when using NTFS Partitions"

What this article basically says is that you need to give read/write
permissions to c:\, c:\winnt, c:\winnt\forms and directories under
c:\Program Files\Microsoft Office.

The article is here ->
http://www.microsoft.com/kb/articles/q169/3/87.htm

has anyone else addressed this problem, because, as it stands now - we
will not be allowed to install Office97 anywhere.


Thanks


Vijay Bhakta

Vijay Bhakta
http://www.thebeach.u-net.com

From: dlebl...@mindspring.com.remove-this (David LeBlanc)
Subject: Re: Security flaw with Office97
Date: 1997/07/17
Message-ID: <33cd6069.942113998@news.mindspring.com>#1/1
X-Deja-AN: 257372836
References: <33cc7dd4.5378994@news.u-net.com> <5qj8et$3s8@apache.dtcc.edu>
X-Server-Date: 17 Jul 1997 00:15:11 GMT
Organization: MindSpring Enterprises
Newsgroups: comp.os.ms-windows.nt.admin.security


we...@apache.dtcc.edu (Ken Weaverling) wrote:

>In article <33cc7dd4.5378...@news.u-net.com>,
>Vijay Bhakta <vi...@thebeach.u-net.com> wrote:
>>Hi,
 
>>We have come across what seems to be a serious flaw with the NTFS
>>security required by Office97.
 
>Oh joy, why am I not surprised? :-(

Maybe because you're overly pessimistic?

>>What this article basically says is that you need to give read/write
>>permissions to c:\, c:\winnt, c:\winnt\forms and directories under
>>c:\Program Files\Microsoft Office.

>I found this hard to believe, but sure 'nuff...
 
>     * The following folders must have read/write permission:
>      C:\
>      C:\Temp
>      C:\Winnt
>      C:\Winnt\Forms
>      C:\Winnt\System32
>      C:\Program Files\Microsoft Office
>      C:\Program Files\Microsoft Office\Office

>This begs the question "What's the point of having security in the first 
>place?"   

Not at all.  If you think about what you can really do here, it isn't
that big a deal.  Somewhat annoying, yes, but nothing you can't work
with.  What you want to do is to allow the users _change_ permission
to these directories at the directory level.  However, the files
within these directories can (and should) be RX (read) for normal
users.  If the user only has change permissions at directory level,
they cannot delete any file they do not own (or have D access to) - so
your system files are quite safe.  The only mischief they can get into
is with the temp files which are actually written.

>How am I supposed to set up a "ZAK app station" if my users can
>install and/or write anything they want from the root directory, bin
>directory, etc?

See above.  Install NT, lock down the system files to RX only for
users, then set the above directories to change for users.  Also, the
\winnt\profiles directory has bad permissions - fix it while you're in
there.  Now install Office as admin - admin now _owns_ all of those
files.  Set directory and file permissions as above, and go back and
loosen the files in the list.  The users can now use Office, but
cannot tamper with any files which are either part of the OS, or files
you put there.

They can also write other new files to those directories, which isn't
an especially good thing, but they certainly can't muck with what was
there before them.  If you want to be clever about it, audit those
directories, and write a script to nuke off any new files which you
don't approve of - dump the event log to text, grep out what you want,
then zap them.

Then you write a nasty-gram to the Office people and tell them to get
a clue about security.  Having stupid apps that think they need to
write all over the system directories is completely ridiculous.
However, just throwing up your hands and deciding it can't be secured
isn't an effective response.  You need to do the best you can with
what you've got - think in terms of solutions.  You may not be able to
make it ideal, but you can certainly make it better.


David LeBlanc           |Why would you want to have your desktop user, 
dlebl...@mindspring.com |your mere mortals, messing around with a 32-bit 
                        |minicomputer-class computing environment?
                        |Scott McNealy

From: jer...@netcom.com (Jeremy Allison)
Subject: Re: Security flaw with Office97
Date: 1997/07/17
Message-ID: <jeremyEDH4Au.Iyp@netcom.com>#1/1
X-Deja-AN: 257494241
Sender: jer...@netcom13.netcom.com
References: <33cc7dd4.5378994@news.u-net.com> <5qj8et$3s8@apache.dtcc.edu> 
<33cd6069.942113998@news.mindspring.com>
Organization: Netcom On-Line Services
Newsgroups: comp.os.ms-windows.nt.admin.security


dlebl...@mindspring.com.remove-this (David LeBlanc) writes:

>Maybe because you're overly pessimistic?

I don't think so.

>>     * The following folders must have read/write permission:
>>      C:\Winnt\System32

>Not at all.  If you think about what you can really do here, it isn't
>that big a deal.  Somewhat annoying, yes, but nothing you can't work
>with.  What you want to do is to allow the users _change_ permission
>to these directories at the directory level.  However, the files
>within these directories can (and should) be RX (read) for normal
>users.  If the user only has change permissions at directory level,
>they cannot delete any file they do not own (or have D access to) - so
>your system files are quite safe.  The only mischief they can get into
>is with the temp files which are actually written.

David, what about the announcement on the NT security list
that the Win32 subsystem will read lower case files before
it reads mixed or upper case files. In which case the
users install a trojan horse using the POSIX subsystem
(which allows files with differing case) directly into
the Win32 directory - effectively replacing a system .DLL.

Now I know that there *aren't* any such trojans right
now. But I bet there are people actively working on them
(and I bet we both know their names too :-).

The missing step here is to go through and rename
*everything* in SYSTEM32 to lower case.

>They can also write other new files to those directories, which isn't
>an especially good thing, but they certainly can't muck with what was
>there before them.  If you want to be clever about it, audit those
>directories, and write a script to nuke off any new files which you
>don't approve of - dump the event log to text, grep out what you want,
>then zap them.

Now that's a good idea - but it's rather a rigmarole to go
through - and it won't fix someone using a transient trojan
.DLL to break security - if a system .DLL can be masked via
case.

>Then you write a nasty-gram to the Office people and tell them to get
>a clue about security.  Having stupid apps that think they need to
>write all over the system directories is completely ridiculous.
>However, just throwing up your hands and deciding it can't be secured

Good luck getting them to listen unless you have a *lot* of
money in your hand - after all, until people stop buying this
stuff as it is so poorly designed, what's the incentive
for it to be improved ? And after all, when people are
actually sending Word documents (an undocumented format) and
seriously proposing that this be made a company 'standard'
(now that's a laugh, Word documents aren't even a standard 
between different versions of Word, let alone across other platforms)
then what choice do you really have ?

Jeremy Allison.