Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: Win2k Permissions bug (fwd)
From: "David LeBlanc" <dleblanc () mindspring com>
Date: Sun, 10 Jun 2001 22:45:46 -0700

This report has some misunderstandings. Details inline -

-----Original Message-----
From: Alfred Huger [mailto:ah () securityfocus com]

This came accross the PenTest mailing list today - thought it
might be of
interest.

Date: 8 Jun 2001 23:06:17 -0000
From: Parth Galen <Parth_Galen () ziplip com>
To: pen-test () securityfocus com
Subject: Win2k Permissions bug

FYI - I am relaying the following note for a friend. I will
get all replies to him ASAP. Thx.
----------------------------------

I been working on this issue through a Microsoft Premier
Support ticket
for about 60 days.  At this time we have not received a resolution nor
does one seem forthcoming.  I am very disappointed at the response, or
lack of response from Microsoft Support on what I believe is a serious
issue.  I feel that you and others should be aware of our findings.

I don't know why you haven't had a response. Someone will probably track it
down Monday and see what happened.

There is apparently a bug in Windows 2000 Server regarding NTFS
permissions.  The symptom is that at the individual file
level the Allow
Inheritable Permissions switch and NTFS file permissions can change
unexpectedly and without notification.  These changes to file security
easily go unknown to both network administrators and end
users. Microsoft
has acknowledged a similar problem referenced in KB article Q266731.
Microsoft has created a hot fix for this issue, however in
testing the hot
fix has not corrected the problem that we have identified.

Example:  In the case where a particular file_s NTFS
permissions are set
different from those of its parent folder and the inheritance
box on the
file has been unchecked, the inherit permissions box on the
file can turn
itself on and the NTFS file permissions will then change to the
permissions defined on the parent folder when the file is modified and
saved.

I'm not aware of any hotfix, and I can show you there isn't a bug (at least
not in NTFS). Here's what I did:

[e:\]md test

[e:\test]cacls .
E:\test BUILTIN\Administrators:(OI)(IO)F
        BUILTIN\Administrators:(CI)F
        Everyone:(OI)(IO)(special access:)
                         GENERIC_READ
                         GENERIC_EXECUTE

        Everyone:(CI)R

Please note that if you check in the GUI, the "Allow inheritable permissions
from parent to propogate" for this directory is checked. Now I created a foo
file:

[e:\test]vi foo

After I created the file, I went into the GUI, changed permissions on the
foo file to allow everyone to write as much foo as they liked, and also
unchecked the inheritable permissions flag. Now let's modify the foo file:

[e:\test]echo "more foo" >> foo

[e:\test]cat foo
foo
"more foo"

Yup, it's been modified. Now go back to the GUI, check the permissions. They
haven't changed.

Now, let's work with the file like some applications do:

[e:\test]vi foo
(changed the file, wrote it out as foo.tmp)

[e:\test]del foo
Deleting E:\test\foo
     1 file deleted

[e:\test]ren foo.tmp foo
E:\test\foo.tmp -> E:\test\foo
     1 file renamed

[e:\test]cacls foo
E:\test\foo BUILTIN\Administrators:F
            Everyone:R

Now it's back to where it was before - that's because it is a new file, and
it inherited the permissions from the parent container (folder, directory,
same thing) just like it is supposed to.

Configuration where the problem has been observed:
 . Windows 2000 Server SP1
 . NT 4.0 SP6a Workstation

No, this is wrong. NT 4.0 doesn't support propogating permissions down the
tree. It can only propogate permissions from parent to child at creation
time. You've observed something similar, but the propogation feature didn't
exist until Win2k.

 . Various applications programs such as: Word 97, Excel 97, Visio 5.0

This is, as FZ would say, the crux of the biscuit. These apps all use a
particular API that doesn't modify the old file, but writes a new one out as
a temp file, and once the new file is safely saved to the drive, nukes the
old one, and renames the new file. I don't recall the API name at the
moment - sorry.

While security
problems are
always serious, this one carries the additional danger of
network security
being altered against the intention of the administrator, while the
administrator is unaware that security changes have taken place.

Actually, this nuisance has been known for quite some time. The way to get
around it is to specify permissions for creator-owner so that the new file
ends up with the permissions you'd like. Also be warned that if a user has
enough permissions to modify a file in this manner, they can modify
permissions on their own if they liked. Once they have created a new file,
they are the owner. The owner of an object can always change the permissions
on that object.

Hope this helps clear things up.

David LeBlanc
dleblanc () mindspring com


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]