This report has some misunderstandings. Details inline - > -----Original Message----- > From: Alfred Huger [mailto:ahat_private] > 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_Galenat_private> > To: pen-testat_private > 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 dleblancat_private
This archive was generated by hypermail 2b30 : Mon Jun 11 2001 - 10:52:22 PDT