Date: Mon, 21 Jun 1999 16:14:41 -0700 Reply-To: Jay Shephard Sender: Windows NT BugTraq Mailing List From: Jay Shephard Subject: No Office 97 in Secure NT Installation Choose Microsoft's Secure NT Install or choose to run Office 97, NOT BOTH. In an effort to further lock-down our systems, we have been setting restrictive NTFS permissions on several directories on our Windows NT Workstation 4.0, SP4 systems. Many of our users then received the following error when opening Excel documents with macros: Microsoft Visual Basic Permission to use object denied. To resolve the issue, we have had to revert the NTFS permissions on the root of WINNT\system32 to Users: Change. It seems that VB creates a temporary file in system32. After calling MS tech support, I was directed to KB Q169387 which explains that the user _must_ have read/write permission to this directory in order to use Office 97. This seems to be contrary to the recommendations in the Security White Paper available at http://www.microsoft.com/ntserver/security/exec/overview/Secure_NTInstall.asp which suggests restricting the permissions to all directories in WINNT. It seems that it should be an easy matter to specify the path that VB should use to create its temp file, but I don't know how. Any ideas? With only read permissions at the root of \System32, it was almost impossible for users to install any software. It will be very disappointing if we cannot resolve this without unrestricting System32. The VB error in Excel seemed to be the only problem with the restrictive permissions. Thank you. Jay Shephard Sr. IT Analyst Fox Liberty Networks ------------------------------------------------------------------------------------- Date: Wed, 23 Jun 1999 09:47:26 -0500 Reply-To: Peter da Silva Sender: Windows NT BugTraq Mailing List From: Peter da Silva Organization: none Subject: Re: No Office 97 in Secure NT Installation In article <9C4B7E39CA6CD21196270000D11BB1F30243ECAC@FOXSN05>, Jay Shephard wrote: >To resolve the issue, we have had to revert the NTFS permissions on the root >of WINNT\system32 to Users: Change. It seems that VB creates a temporary >file in system32. I have commented on this blatant security hole in NT before: to wit, that you can not productively use NT with other Microsoft software without granting write permission to numerous locations that contain shared executable code. If this wasn't the case, anti-virus protection on NT would consist of "apply these permissions to the registry and file system, and open "EXE" attachments with Winzip". Please, folks, bitch long and loud at Microsoft until they wake up and fix it. -- This is The Reverend Peter da Silva's Boring Sig File - there are no references to Wolves, Kibo, Discordianism, or The Church of the Subgenius in this document "Be vewy vewy quiet...I'm hunting Jedi." -- Darth Fudd ------------------------------------------------------------------------------------- Date: Thu, 24 Jun 1999 17:34:12 +0000 Reply-To: Vesselin Bontchev Sender: Windows NT BugTraq Mailing List From: Vesselin Bontchev Subject: Re: No Office 97 in Secure NT Installation Comments: To: peter@TARONGA.COM In-Reply-To: <7kqs1u$53q@bonkers.taronga.com> from Peter da Silva at "Jun 23, 99 09:47:26 am" Peter da Silva writes: > If this wasn't the case, anti-virus protection on NT would consist of > "apply these permissions to the registry and file system, and open > "EXE" attachments with Winzip". :-). I understand that this is a metaphor but some of the readers who don't know better might be mislead by such a statement. Remember, folks, discretionary access controls cannot stop computer viruses - they can only slow down their spread. Even if you could effectively block access to the vital directories, this wouldn't help you if you, the Administrator, run an infected executable. The virus runs with the privileges of the user who has executed the infected program and can do anything that user can do. Sure, that would mean that an infected normal user can infect only his/her own files (instead of the whole server) - but, because of the transitivity of the information sharing, the virus will eventually spread further, just more slowly (e.g., one of that user's infected executables will be executed by some other user sooner or later). Also, do not forget macro viruses. They can infect your documents and you cannot block access to the documents. It's nice, of course, if you can prevent the users from infecting everybody else by infecting the common global template - but even in that case a virus will still spread from one document to another. The bottom line is, even with better access controls, you would still need anti-virus software; just your life would be a bit easier. :-) Regards, Vesselin -- Vesselin Vladimirov Bontchev, not speaking for FRISK Software International, Postholf 7180, IS-127, Reykjavik, Iceland producers of F-PROT. e-mail: bontchev@complex.is, tel.: +354-561-7273, fax: +354-561-7274 PGP 2.6.2i key fingerprint: E5 FB 30 0C D4 AA AB 44 E5 F7 C3 18 EA 2B AE 4E ------------------------------------------------------------------------------------- Date: Thu, 24 Jun 1999 10:44:32 -0700 Reply-To: Paul Leach Sender: Windows NT BugTraq Mailing List From: Paul Leach Subject: Re: No Office 97 in Secure NT Installation Comments: To: Peter da Silva > -----Original Message----- > From: Peter da Silva [mailto:peter@TARONGA.COM] > Sent: Wednesday, June 23, 1999 7:47 AM > To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM > Subject: Re: No Office 97 in Secure NT Installation > > > In article <9C4B7E39CA6CD21196270000D11BB1F30243ECAC@FOXSN05>, > Jay Shephard wrote: > >To resolve the issue, we have had to revert the NTFS > permissions on the root > >of WINNT\system32 to Users: Change. It seems that VB creates > a temporary > >file in system32. > > I have commented on this blatant security hole in NT before: > to wit, that > you can not productively use NT with other Microsoft software > without granting > write permission to numerous locations that contain shared > executable code. Please be accurate: the problem is with the apps, not Windows NT. The target platform for most existing Windows apps, including Microsoft's to be sure, was Windows 95. Which as we all know, can't be locked down against other users of the same machine. It was not possible, until recently, to convince application software vendors that the Windows NT market was big enough to warrant making sure that their products ran on a locked down NT machine. That's changing. For example, Office 2000 has been fully tested on locked down Windows 2000 systems; the templates to lock down Windows 2000 machines are included in the box, and can be deployed centrally via policy. And such testing will be required to get the Windows logo in the future. > > If this wasn't the case, anti-virus protection on NT would consist of > "apply these permissions to the registry and file system, and > open "EXE" > attachments with Winzip". Nonsense. None of the recent viruses used the fact that the windows or system32 directory could have files added to it, so fixing it wouldn't have helped. In fact, just the latter of your two prescriptions (open .exes with Winzip) would have handled the latest virus (Worm.Explorer.Zip) all by itself. And Melissa would have been stopped if Word was configured to not automatically run startup macros. Office 2000 is even better -- it is by default set to not run macros at all unless they are signed. In order to stop viruses in organizations, ordinary end users have to be prevented from runnning any executable not "blessed" by someone in authority. Paul ------------------------------------------------------------------------------------- Date: Tue, 22 Jun 1999 18:39:11 -0500 Reply-To: Silona Bonewald Sender: Windows NT BugTraq Mailing List From: Silona Bonewald Subject: No Office 97 in Secure NT Installation... partially... Comments: To: rkimedes@ccwf.cc.utexas.edu, Charles.Denny@bus.utexas.edu Well I asked my girlfriend, Jenna, at the UT business school computer center (over 200+ computers) here in Austin, Texas about this and here is what she and her supervisor Charles said... Jenna said: It looks like what we did was set the permissions on system32 to Users(RWX)(RWXD) at the directory level and then when you go inside the directory all of the files are set to users(RX) so that people can create files in there, and if they are the creator/owner, they can delete them, but they don't have access to any of the pre-existing files in there. Does that make sense? So they can put new files in there (for excel) but they can't modify any of the system files. Which is not ideal, but it makes the systems at least stable enough to be able to go a year with being in constant use and without being rebuilt. Charles, is this an accurate assessment? Charles responded: Jenna, That's the gist of it. However there are few other areas where you need to give certain permissions to DLLs and to files/paths in the Office directory as well. We have all those settings in the C2Config file for the NTFS. This has always been an annoying aspect of NT. Charles Jenna then responded: Ok, the office section of c2config looks like this: [%SystemDrive%\Program Files\Microsoft Office\Office] BUILTIN\Users = RWX,RWXD BUILTIN\Administrators = FullControl SYSTEM = FullControl [%SystemDrive%\Program Files\Microsoft Office\Office\*.mda] BUILTIN\Users = RWX BUILTIN\Administrators = FullControl SYSTEM = FullControl [%SystemDrive%\Program Files\Microsoft Office\Office\*.mde] BUILTIN\Users = RWX BUILTIN\Administrators = FullControl SYSTEM = FullControl [%SystemDrive%\Program Files\Microsoft Office\Office\*.mdt] BUILTIN\Users = RWX BUILTIN\Administrators = FullControl SYSTEM = FullControl This makes the wizards work. Front Page has its own issues, but since it's not part of Office 97, per se, I didn't include it. Jenna Hope that Helps everyone, Thanks again Jenna and Charles (my heros) Silona -- _______________________________________________ Silona Bonewald Web Administratrix "Q: What do you do exactly? " "A: What needs to be done exactly and I'll do it." ------------------------------------------------------------------------------------- Date: Thu, 24 Jun 1999 18:45:51 +0000 From: Vesselin Bontchev To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: No Office 97 in Secure NT Installation Paul Leach writes: > And Melissa would have been stopped if Word was configured to not > automatically run startup macros. Not true. Melissa does not use any auto macros at all. It relies on event handlers (Document_Open and Document_Close). > Office 2000 is even better -- it is by default set to not run macros > at all unless they are signed. The only problem being that once you sign a VBA6 project, it *remains* signed - even if you modify it. Or if a virus modifies it on your behalf by infecting it. Regards, Vesselin -- Vesselin Vladimirov Bontchev, not speaking for FRISK Software International, Postholf 7180, IS-127, Reykjavik, Iceland producers of F-PROT. e-mail: bontchev@complex.is, tel.: +354-561-7273, fax: +354-561-7274 PGP 2.6.2i key fingerprint: E5 FB 30 0C D4 AA AB 44 E5 F7 C3 18 EA 2B AE 4E