Re: Double clicking on MS Office documents from Windows Explorer may execute arbitrary programs in some cases

[Francis Favorini <francis.favorini () DUKE EDU>]

aleph@SECURITYFOCUS.RBITRARYPROGRAMSINSOMECASESCOM wrote...
> Now the attacker only needs to drop a malicious DLL into the
> same folder as a file he knows the CEO opens on a regular basis on the
> file server and wait until he opens it and the DLL has not
> already been loaded. This is not an uncommon state.

True, but you can protect the user from himself by setting appropriate
permissions on all corporate shares.  First rule: data shares are for data
only, not executables.  Second rule: users may write to data shares, but not
other shares.  Then the admin must do two things:
  1) Set the NTFS permissions so that users may not Execute any files on the
data share.
  2) Set the Share permissions to Everyone:Change instead of the default
Everyone:Full.
This latter protection prevents users from changing the NTFS permissions on
files/directories, *even if they are the owner*.  An admin can also set up a
separate Programs share for executables, but no users should be able to
write to this share at all.

Of course the above does not protect against a user being tricked into
opening a document from a share under the attacker's control somewhere out
on the Internet.  "Standard firewall practices" blocking incoming and
outgoing NBT/CIFS/SMB should take care of that. ;-)

Note however that you cannot protect the user from files on *local* drives
in quite the same iron-clad way.  You can set NTFS permissions to disallow
Execute on files, but the Owner of the file can override this by changing
the ACL on the file.  I think this is a major flaw in NTFS.  An admin should
be able to set NTFS ACLs on a directory such that users may write to the
directory, but cannot then change the ACLs on the files they create.  (If
there is a way to do this now, please let me know!)  The owner of a file
should not have any special ability to reset the ACL.  If needed, the admin
could specifically grant Change Permissions access to CREATOR/OWNER and
allow that to propagate from the directory to files created in it.  Am I the
only one who would like to see this changed?

Someone else brought up mail clients writing attachments to Temp directories
and Zip files containing .DOC and .DLL files.  I always set up Temp
directories to not allow Executing files, and I try to limit the number of
places where users can write files to the absolute minimum.  This is not
always easy with certain ill-behaved applications (like everything from
Adobe).

> In the same vein, just because most people are protected by a firewall
> it does not mean SMB should attempt to authenticate via NTLM
> automatically with anyone. It should observe the Security Zones settings
> the same way IE does, and now the W2K telnet client.

Absolutely agreed.  We need more control over the OS doing things
automatically.

        -Francis

P.S. <rant> Is it just me or does the new Permissions editor have major
problems?  If you have a file with inherited ACEs and then add one extra
permission (e.g., you want to add Users:Write where Users:Read is already
inherited) directly to the file, it copies every inherited ACE as a direct
ACE, which seems unnecessary.  Furthermore, you can't then delete those
copied ACEs.  The only way to get rid of them is to reset the whole ACL.
This is on NT SP6a.  It has also crashed on me a few times!</rant>