Message-ID: <096A04F511B7FD4995AE55F13824B833212817@banneretcs1.local.banneretcs.com>
Date: Sat, 10 Mar 2007 11:54:53 -0500
From: "Roger A. Grimes" <roger@...neretcs.com>
To: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>
Subject: RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

Two things regarding this ongoing (civil) flame war:

1. I was wrong about most versions of Linux having the same inheritance
behavior as Windows. Dead wrong. And several people have wrote to
correct me. Thank you. The search for truth is more important than my
ego. <grin> Before I wrote that statement, I dropped into a VM of
knoppix that I had on my desktop to test. It's default umask is 000, and
thus the normal inheritance rules applied. After many people wrote, I
realized I used Foundstone's FSLive distro, which is a variation of
Knoppix, intentionally weakened for the classes we teach.  It goes to
show that one sample finding does not a population make.

2. My bone of contention with the original poster, is not that he's an
idiot. He isn't. I'm objecting to his obscure insecurity scenario that
he uses to start the discussion (i.e. private folder created under a
public folder).

How many of you have intentionally created a private folder underneath a
public folder, where the public folder gave Modify/Change permissions to
the larger group?

It's got to be a small minority, and I'd question why even those people
did it.

I've been a sysadmin for 20 years and never done it. If someone was to
come to me and tell me they were going to do it, I'd caution them
against it. Not because of the poster's original concern, but because on
the onset it looks like bad security policy looking for trouble. I'd
recommend that a separate private folder be created every time.

Where I have seen public folders used with private folders underneath,
the larger group did not have Change/Modify permissions to the parent
public folder. They had Read and List, and  couldn't modify other
people's child folders. That's very common.

The rest of his posting is a NTFS permissions 101 class. we've all been
taught that if you delete and re-create an object in Windows, even with
the same name, it isn't the same object. This applies to files, folders,
groups, users...every Windows object without exception.  No surprise
there. We also know whoever creates the object is the Creator Owner and
gets Full Control. It's why Microsoft added the creator Owner SID so
that we could change the default behavior if we didn't like it.  So, I
don't see the big "lesson" in his posting.

Now, before I get more people defending the original poster, I think his
exact same argument could be applied to a much more common scenario that
I see all the time, perhaps in 50% of all companies that I have audited.
It is where the Everyone group has Full Control to a public Share.
Unless you intend that anyone in your company can change permissions,
it's a bad thing to do.  And don't start with that Windows makes that
the automatic default...that changed in XP. The default Share permission
is now Read, and the underlying NTFS permission (which wins in a
conflict), has never been Everyone Full Control by default in any
version of Windows since NT 4.0.

I'd rather the poster take the more popular problem I've mentioned in
the paragraph above and make the exact same argument, which is, if you
make a security configuration mistake (because all of these scenarios
are mistakes pure and simple), other users can use a timing attack and
deception to give themselves elevated access to your personal files.  

It's still a valid lesson, but I'm not mentally tripping over a strange
start out assumption.

And in the end, the solution is an easy one:
1. Don't intentionally configure security weaknesses.
2. If you absolutely need to give users the ability to create private
folders under a public folder where users have Modify/Change or Full
Control permissions, you have four easy defenses:
	a. Change default inheritance
	b. Enable the Deny-Delete files and subfolders permission.
	c. Change the Creator Owner SID's default permissions for that
folder.
	d. Make them separate folders.
Roger

*****************************************************************
*Roger A. Grimes, InfoWorld, Security Columnist 
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: roger_grimes@...oworld.com or roger@...neretcs.com
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*****************************************************************

Powered by blists - more mailing lists