RE: Win2k Permissions bug (fwd)

["David LeBlanc" <dleblanc () mindspring com>]

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