Is This Behavior a Security Hole in Windows XP?

[Will]

The general rule in Windows XP, Windows 2000, and Windows 2003 is that in a
file access control list (i.e., DACL), the deny permissions are scanned
first, and only after excluding the requestor from the Deny list are the
Accept list entries scanned. It turns out that the kernel does not have
this restriction, but the GUI tools we use in Windows XP to set file
security always place the Deny list entries at the top.

Well, I have made the ugly discovery today on a Windows XP SP2 system that
if you set a folder to inherit permissions, then attempt to add some
additional user or group objects into the list, that now those additional
objects are placed at the *top of the DACL*. If those new access rule
entries are Accept conditions, then they will be executed *before* the Deny
entries in the inherited list, and your Deny list does NOT get priority
execution.

At very least, this very surprising behavior is not well documented. But
here is why I consider this to be a very serious bug. Any intruder who
manages to get into a system now need only put a duplicate entry into the
DACL to in effect reverse its meaning. If you started with:

Deny ANONYMOUS All
Deny Guests All
Accept Administrators All
Accept SYSTEM All

The user can simply add a rule such as:

Accept ANONYMOUS All

The fully resolved list in the Advanced view of the DACL will now be:

Accept ANONYMOUS All
Deny ANONYMOUS All
Deny Guests All
Accept Administrators All
Accept SYSTEM All

And sure enough, the Accept rule at the top will execute prior to the Deny
rule, and the intruder has now introduced a very subtle back door into the
system that only the most observant administrator could possibly catch.
The default view of the DACL would only show one entry for ANONYMOUS and you
would have to select it to see that both Accept and Deny columns were
checked, and many administrators would wrongly assume that the Deny entries
were going to execute first, when in the special case I have found they will
execute after the Accept entry.

Since most of us use inheritance widely on our file systems, this is not an
obscure case. It is in fact the common case. Can someone explain to me
if this is a "feature" and why it should be so?

 

[Steven L Umbach]

Yes that has been the behavior since Windows 2000 and I would not call it a
security hole though it would be for the user that does not understand that
and probably most don't. I don't know why MS decided to implement such
behavior. You comment on if an intruder gains access to the system then all
they need to do... Well they would most likely need and have
system/administrator access to change such permissions and their ability to
do that would be among the least of your worries at such point. Where it
really gets confusing is where you see an inherited deny and an inherited
allow and the allow prevails. This can be the case if the allow permission
is configured "closer" in the path to the object than the deny was. I always
suggest that when possible users should not use deny permissions as lack of
permission is an implicit deny and because of the way permissions
inheritance is applied often users think they have a secure access control
list when they do not. --- Steve

http://technet2.microsoft.com/Windo...f26f-4223-9af6-49540a9451021033.mspx?mfr=true

Notes

. Inherited Deny permissions do not prevent access to an object if the
object has an explicit Allow permission entry.

. Explicit permissions take precedence over inherited permissions,
even inherited Deny permissions.

 

[Guest]

they would most likely need and have
system/administrator access to change such permissions and their ability to
do that would be among the least of your worries at such point.

Agreed. This issue would in most cases not allow an attacker to gain
additional access, nor would fixing it seem likely to increase security
against a user that has already accessed the system.