[3764] in bugtraq
Re: (Fwd) RE: [NTSEC] Delete permissions on files
daemon@ATHENA.MIT.EDU (Ken Cross)
Sat Dec 7 22:19:21 1996
Date: Sat, 7 Dec 1996 21:06:15 -0600
Reply-To: Ken Cross <kencross@earthlink.net>
From: Ken Cross <kencross@earthlink.net>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
I agree completely with your sentiments that it's a serious problem.
However, (unfortunately), it's not a bug - it's a feature and it ain't
gonna get "fixed".
It's a characteristic of directories that allow anyone with "Full
Control" permission on that directory to delete files in that directory,
regardless of the protections set on the file itself. The idea is that
if you have full control over a directoty, that includes removing files
from that directory (i.e., deleting them). In this regards, deleting
the file is considered a directory operation, not a file operation.
Note that this *doesn't* happen if you have RWXDPO permissions on the
directory. If you have Full Control, then you have an additional
(hidden) permission called File Delete Child (FDC). There is no
explicit mechanixm to disable FDC - you have to change permissions from
Full Control to RWXDPO.
This is for POSIX compliance (the same thing happens on most Unix
systems) - that's why "MS has no plans to fill this hole". However, MS
could do some other things to help, such as set RWXDPO as default
permissions rather than Full Control, or (better still) make the FDC
permission explicit so you can decide to disable it.
I hope they do something - someone's gonna get bit really bad.
Ken
David LeBlanc wrote:
>
> At 12:34 12/6/96 -0500, you wrote:
>
> >I just read this morning in the Nov. 96 issue of NT magazine
> >that there _is_ a bug in NTFS permissions. "If you set a file
> >to R (read-only) access for Everyone, users can still delete
> >the file although Everyone lacks D (delete) access.
> >Apparently, MS has no plans to fill this hole." -From
> >Ctrl-Alt-Del column, pg 184.
>
> It is worse than that.
>
> It doesn't matter _who_ it is set to read-only. The file can be read-only
> administrators, and I can still delete it. Plus, even if you go into
> "special" permissions", and remove the execute flag, it can _still_ be deleted.
>
> [c:\]cacls foo
> C:\foo BUILTIN\Administrators:R
>
> [c:\]del foo
> Deleting C:\foo
> 1 file deleted 1,536 bytes freed
>
> [c:\]dir foo
>
> Volume in drive C is unlabeled Serial number is 8494:9621
> 4DOS/NT: The system cannot find the file specified.
> "C:\foo"
> bytes in 0 files and 0 dirs
> 265,867,776 bytes free
>
> What I have not tested is if it is read-only to one set of users, and
> another tries to delete it.
>
> This has _extremely_ serious implications, as this would allow _any_ user
> who has read access to a file to delete it, and replace it with a trojan.
>
> IMHO, Microsoft should put up a patch for this one ASAP.
>
> I've also not tested it under 3.51.
>
> I don't know who told the columnist that MS has no plans to fix it, but they
> should be made aware of exactly how serious such a problem is. The fact it
> has shown up in a magazine means that it was discovered a minimum of 2
> months ago.
> I'd also like to know how it was that this guy found it, and the info didn't
> get back to the right people at MS. From my experience with them, if they'd
> known about it, it would have been patched - which tells me that the
> columnist didn't manage to tell anyone with enough sense to let the right
> people know. Plus, telling a columnist that MS has no plans to fix
> something this serious constitutes extremely bad press and coneys the
> impression they don't care about security issues. I don't feel like that is
> a correct impression, but it is extremely dumb for someone to tell a
> columnist such a thing.
>
> -----------------------------------------------------------
> David LeBlanc | Voice: (770)395-0150
> Internet Security Systems, Inc. | Fax: (404)395-1972
> 41 Perimeter Center East | E-Mail: dleblanc@iss.net
> Suite 660 | www: http://www.iss.net/
> Atlanta, GA 30328 |
