You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1998/01/04 06:28:03 UTC
sigh. iis...
Looking at IIS some more,
http://myserver/cgi-bin/mycgi.exe/../../foo/ will access the same thing as
http://myserver/foo/
That's kinda broken, no?
Only problem is that Apache does it too.
With Apache, it logs it as /cgi-bin/mycgi.exe/../../foo (IIS doesn't).
This means that anyone can sneak around any billing based on logfile
analysis.
NS enterprise 3.x seems to just deny all requests with a /../ in the
request anywhere.
Re: sigh. iis...
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 6 Jan 1998, Dean Gaudet wrote:
> There's rumoured to be a registry setting that disables short names on
> NTFS.
http://premium.microsoft.com/support/ntserver/serviceware/06900084.asp
It will break some things though.
like "edit".
>
> Dean
>
> On Tue, 6 Jan 1998, Martin Kraemer wrote:
>
> > On Mon, Jan 05, 1998 at 10:18:12AM +0000, Ben Laurie wrote:
> > > BTW, on the question of IIS serving short names without reference to
> > > security, surely this must be an NT bug?
> >
> > Wasn't this bug reported to exist in an NTFS? Are there short names at all
> > in NTFS? (What for?)
> >
> > Martin
> > --
> > | S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
> > | ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
> > | N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
> > ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
> >
>
Re: sigh. iis...
Posted by Dean Gaudet <dg...@arctic.org>.
There's rumoured to be a registry setting that disables short names on
NTFS.
Dean
On Tue, 6 Jan 1998, Martin Kraemer wrote:
> On Mon, Jan 05, 1998 at 10:18:12AM +0000, Ben Laurie wrote:
> > BTW, on the question of IIS serving short names without reference to
> > security, surely this must be an NT bug?
>
> Wasn't this bug reported to exist in an NTFS? Are there short names at all
> in NTFS? (What for?)
>
> Martin
> --
> | S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
> | ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
> | N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
> ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
>
Re: sigh. iis...
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Mon, Jan 05, 1998 at 10:18:12AM +0000, Ben Laurie wrote:
> BTW, on the question of IIS serving short names without reference to
> security, surely this must be an NT bug?
Wasn't this bug reported to exist in an NTFS? Are there short names at all
in NTFS? (What for?)
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: sigh. iis...
Posted by Ben Laurie <be...@algroup.co.uk>.
BTW, on the question of IIS serving short names without reference to
security, surely this must be an NT bug? Or is IIS enabled to bypass
security? Is that even possible? What happens when you do the same thing
with Apache (hmmm ... I guess Apache never uses the short name, so....)?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: sigh. iis...
Posted by Ben Laurie <be...@algroup.co.uk>.
Brian Behlendorf wrote:
>
> At 11:34 AM 1/4/98 +0000, Ben Laurie wrote:
> >Marc Slemko wrote:
> >
> >> Why does Apache need to resolve /../ at all?
> >
> >Otherwise people can avoid security.
>
> I think what Marc is saying is, why not throw an error any time .. appears
> for a file path, though we should still allow it for PATH_INFO and after a
> ?. Seems reasonable to me, any client which sends that after resolving a
> HREF="../foo" relative URL has gotta be busted anyways.
If that's what he was saying, then I agree.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: sigh. iis...
Posted by Brian Behlendorf <br...@organic.com>.
At 11:34 AM 1/4/98 +0000, Ben Laurie wrote:
>Marc Slemko wrote:
>
>> Why does Apache need to resolve /../ at all?
>
>Otherwise people can avoid security.
I think what Marc is saying is, why not throw an error any time .. appears
for a file path, though we should still allow it for PATH_INFO and after a
?. Seems reasonable to me, any client which sends that after resolving a
HREF="../foo" relative URL has gotta be busted anyways.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: sigh. iis...
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> On Sun, 4 Jan 1998, Chuck Murcko wrote:
>
> > Marc Slemko wrote:
> > >
> > > Looking at IIS some more,
> > >
> > > http://myserver/cgi-bin/mycgi.exe/../../foo/ will access the same thing as
> > > http://myserver/foo/
> > >
> > > That's kinda broken, no?
> > >
> > > Only problem is that Apache does it too.
> > >
> > > With Apache, it logs it as /cgi-bin/mycgi.exe/../../foo (IIS doesn't).
> > > This means that anyone can sneak around any billing based on logfile
> > > analysis.
> > >
> >
> > Are you saying it does this even without a ScriptAlias directive? That's
> > not good.
>
> No, I wasn't saying that since I didn't bother looking. But yes, it does
> that without a ScriptAlias.
>
> There are two different problems here.
>
> The problem with doing it for a ScriptAlias is that it is yet another
> messed up CGI thing; the whole concept of the PATH_INFO mapping to the
> filesystem makes me unhappy but, obviously, some of it has to be done to
> make it CGI. What is in the PATH_INFO should not allow /../ to go above
> the CGI. This is, however, hard to parse in the current structure.
>
> The second issue is messing up logs.
>
> Why does Apache need to resolve /../ at all?
Otherwise people can avoid security.
> If it does, I really think
> it should do a substitution and not just a parsing.
That I'd agree with. It should also figure out what is path and what is
path info.
Actually, I seem to remember that .. should be resolved by the client,
so perhaps the simple answer is to ban it altogether.
> Even worse: http://site/~user/../~otheruser/
Umm. Yes. That is rather difficult to deal with.
>
> I would be willing to bet that nearly any log parser would end up
> attributing the hits to user insted of otheruser. Where hits are billed
> or restricted, this can be deadly. Obvious if you look at the logs, but
> not if they are just automatically summarized.
>
> >
> > > NS enterprise 3.x seems to just deny all requests with a /../ in the
> > > request anywhere.
Very sensible.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: sigh. iis...
Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 4 Jan 1998, Chuck Murcko wrote:
> Marc Slemko wrote:
> >
> > Looking at IIS some more,
> >
> > http://myserver/cgi-bin/mycgi.exe/../../foo/ will access the same thing as
> > http://myserver/foo/
> >
> > That's kinda broken, no?
> >
> > Only problem is that Apache does it too.
> >
> > With Apache, it logs it as /cgi-bin/mycgi.exe/../../foo (IIS doesn't).
> > This means that anyone can sneak around any billing based on logfile
> > analysis.
> >
>
> Are you saying it does this even without a ScriptAlias directive? That's
> not good.
No, I wasn't saying that since I didn't bother looking. But yes, it does
that without a ScriptAlias.
There are two different problems here.
The problem with doing it for a ScriptAlias is that it is yet another
messed up CGI thing; the whole concept of the PATH_INFO mapping to the
filesystem makes me unhappy but, obviously, some of it has to be done to
make it CGI. What is in the PATH_INFO should not allow /../ to go above
the CGI. This is, however, hard to parse in the current structure.
The second issue is messing up logs.
Why does Apache need to resolve /../ at all? If it does, I really think
it should do a substitution and not just a parsing.
Even worse: http://site/~user/../~otheruser/
I would be willing to bet that nearly any log parser would end up
attributing the hits to user insted of otheruser. Where hits are billed
or restricted, this can be deadly. Obvious if you look at the logs, but
not if they are just automatically summarized.
>
> > NS enterprise 3.x seems to just deny all requests with a /../ in the
> > request anywhere.
>
> --
> chuck
> Chuck Murcko The Topsail Group West Chester PA
> USA
> chuck@topsail.org
>
Re: sigh. iis...
Posted by Chuck Murcko <ch...@topsail.org>.
Marc Slemko wrote:
>
> Looking at IIS some more,
>
> http://myserver/cgi-bin/mycgi.exe/../../foo/ will access the same thing as
> http://myserver/foo/
>
> That's kinda broken, no?
>
> Only problem is that Apache does it too.
>
> With Apache, it logs it as /cgi-bin/mycgi.exe/../../foo (IIS doesn't).
> This means that anyone can sneak around any billing based on logfile
> analysis.
>
Are you saying it does this even without a ScriptAlias directive? That's
not good.
> NS enterprise 3.x seems to just deny all requests with a /../ in the
> request anywhere.
--
chuck
Chuck Murcko The Topsail Group West Chester PA
USA
chuck@topsail.org