Re: Nifty Security hole on Several NT Based Web Servers

[aleph1 () DFW NET (Aleph One)]

---------- Forwarded message ----------
Date: Fri, 9 Jan 1998 09:37:25 -0700
From: Marc Slemko <marcs () ZNEP COM>
To: NTBUGTRAQ () LISTSERV NTBUGTRAQ COM
Subject: Re: Nifty Security hole on Several NT Based Web Servers

On Fri, 9 Jan 1998, Olivier Gerschel wrote:

> On Friday, January 09, 1998, Greg Skafte [SMTP:skafte () WORLDGATE COM] wrote:
>
> > A collegue of mine discovered a very interesting bug in several Web
> > server packages.  if you protect a file that is not 8.3 in its makeup
> > you can often access the canonical name without restriction. EG:
> >
> > if a file named  "somelongfile.htm"  and you protect it then you can
> > access somef~1.htm  if somel~1.htm is the canonical name. (don't recall
> > the corect NT term). This also applies to directory names as well.
> >
> > We have notified some of the affected vendors but haven't tested all
> > the various NT Web servers.
> >
> > Know to be affected are IIS 4.0, Netscape Enterprise 3.0x and Website
> > Pro don't recall the version.
>
> Verified here with IIS4.0. It seems like you can fix this behavior if you
> remove the IUSER_Machine generic anonymous IIS account from the ACL of the
> protected resource.

Sortof.

The way this works is that filesystem level restrictions (ie. from the
properties menu) are always applied correctly because they are not tied to
the long name, but just to the name as stored on disk, which the long name
refers to.  This means that, AFAIK, IIS3 does not have any problems with
this because you are incapable of specifying directory level restrictions
anywhere other than at the file system level.  The problem in IIS4 is just
with the new feature to allow you to specify directory and file level
restrictiosn from the management console.