You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1998/01/08 05:05:44 UTC

Re: cvs commit: apachen/src/main http_request.c

This breaks stuff.  Consider:

    GET http://abcdef/foo%2fbar

and

    <Directory proxy:http://abcdef/foo/bar>
    ...
    </Directory>

Of course, this example is already broken by doing this:

    GET http://abcdef:80/foo/bar

Or at least I think it is.

Perhaps we should take this time to completely blow away the "special"
proxy r->filename crap.  These things are URIs and should never see
the light of day in the filesystem code.  They're handled just fine
by <Location>.

Dean

On 8 Jan 1998 marc@hyperreal.org wrote:

> marc        98/01/07 19:56:09
> 
>   Modified:    src/main http_request.c
>   Log:
>   Move os_canonical_filename call to after the section where
>   !os_is_path_absolute names are dealt with to prevent bogus munging
>   of things like proxy:
>   
>   May(?) still cause problems with regex stuff, but fixes proxy caching
>   on win32.
>   
>   Reviewed by:	Ben Laurie
>   
>   Revision  Changes    Path
>   1.98      +1 -1      apachen/src/main/http_request.c
>   
>   Index: http_request.c
>   ===================================================================
>   RCS file: /export/home/cvs/apachen/src/main/http_request.c,v
>   retrieving revision 1.97
>   retrieving revision 1.98
>   diff -u -r1.97 -r1.98
>   --- http_request.c	1998/01/07 16:46:12	1.97
>   +++ http_request.c	1998/01/08 03:56:08	1.98
>   @@ -286,7 +286,6 @@
>            return OK;
>        }
>    
>   -    r->filename   = os_canonical_filename(r->pool, r->filename);
>        test_filename = pstrdup(r->pool, r->filename);
>    
>        /*
>   @@ -337,6 +336,7 @@
>            return OK;
>        }
>    
>   +    r->filename   = os_canonical_filename(r->pool, r->filename);
>        no2slash(test_filename);
>        num_dirs = count_dirs(test_filename);
>    
>   
>   
>   
> 


Re: cvs commit: apachen/src/main http_request.c

Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 8 Jan 1998, Dean Gaudet wrote:

> 
> 
> On Thu, 8 Jan 1998, Ben Laurie wrote:
> 
> > Dean Gaudet wrote:
> > > 
> > > This breaks stuff.  Consider:
> > > 
> > >     GET http://abcdef/foo%2fbar
> > 
> > Uh?
> 
> Ok consider GET http://abcdef/foo%2ebar and
> 
> <Directory proxy:http://abcdef/foo.bar>
> 
> The former will is equivalent to the latter but after Marc's change will
> not be considered so.  i.e. security hole. 

os_canonical_filename plays no part in this anyway.  It is bogus to apply
os_canonical_filename to _remote_ URLs because it is _os_; we don't know
what OS the remote runs and these aren't fs paths.

In any case, we _can't_ fully protect against this.

http://site//foo

and

http://site/foo

_could_ refer to two different documents.  It just happens that they don't
on Apache servers.  Pretending they are the same would be bogus.  That may
not be the best examples, there are others.  %-encoding is (generally) a
different case.

url variance sucks, but it is very hard to avoid allowing stuff like this
through the proxy.  How about paths with "/../" in?  Denying such things
at the proxy wouldn't be smart.

> 
> (I switched the example from %2f to %2e so that we don't have to think
> about %2f issues, they're special.)
> 
> Dean
> 
> > 
> > > 
> > > and
> > > 
> > >     <Directory proxy:http://abcdef/foo/bar>
> > >     ...
> > >     </Directory>
> > > 
> > > Of course, this example is already broken by doing this:
> > > 
> > >     GET http://abcdef:80/foo/bar
> > > 
> > > Or at least I think it is.
> > > 
> > > Perhaps we should take this time to completely blow away the "special"
> > > proxy r->filename crap.  These things are URIs and should never see
> > > the light of day in the filesystem code.  They're handled just fine
> > > by <Location>.
> > 
> > doubleplusone.
> > 
> > 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: cvs commit: apachen/src/main http_request.c

Posted by Dean Gaudet <dg...@arctic.org>.

On Thu, 8 Jan 1998, Ben Laurie wrote:

> Dean Gaudet wrote:
> > 
> > This breaks stuff.  Consider:
> > 
> >     GET http://abcdef/foo%2fbar
> 
> Uh?

Ok consider GET http://abcdef/foo%2ebar and

<Directory proxy:http://abcdef/foo.bar>

The former will is equivalent to the latter but after Marc's change will
not be considered so.  i.e. security hole. 

(I switched the example from %2f to %2e so that we don't have to think
about %2f issues, they're special.)

Dean

> 
> > 
> > and
> > 
> >     <Directory proxy:http://abcdef/foo/bar>
> >     ...
> >     </Directory>
> > 
> > Of course, this example is already broken by doing this:
> > 
> >     GET http://abcdef:80/foo/bar
> > 
> > Or at least I think it is.
> > 
> > Perhaps we should take this time to completely blow away the "special"
> > proxy r->filename crap.  These things are URIs and should never see
> > the light of day in the filesystem code.  They're handled just fine
> > by <Location>.
> 
> doubleplusone.
> 
> 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: cvs commit: apachen/src/main http_request.c

Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> 
> This breaks stuff.  Consider:
> 
>     GET http://abcdef/foo%2fbar

Uh?

> 
> and
> 
>     <Directory proxy:http://abcdef/foo/bar>
>     ...
>     </Directory>
> 
> Of course, this example is already broken by doing this:
> 
>     GET http://abcdef:80/foo/bar
> 
> Or at least I think it is.
> 
> Perhaps we should take this time to completely blow away the "special"
> proxy r->filename crap.  These things are URIs and should never see
> the light of day in the filesystem code.  They're handled just fine
> by <Location>.

doubleplusone.

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: cvs commit: apachen/src/main http_request.c

Posted by Dean Gaudet <dg...@arctic.org>.
I didn't say it broke stuff on unix alone.  I said that it broke stuff
period.  Or at least I'm assuming it broke stuff.  If you're right and it
was already broken then ignore me.  It probably is already broken, and we
probably already do have many ways to bypass <Directory>/<Location>
security by using %xx escapes.

Dean

On Thu, 8 Jan 1998, Marc Slemko wrote:

> On Wed, 7 Jan 1998, Dean Gaudet wrote:
> 
> > This breaks stuff.  Consider:
> 
> How can it break stuff on Unix when it doesn't do anything on Unix?
> 
> If you want to argue stuff is already broken on Unix, fine, but... it
> isn't broken by this change.
> 
> > 
> >     GET http://abcdef/foo%2fbar
> > 
> > and
> > 
> >     <Directory proxy:http://abcdef/foo/bar>
> >     ...
> >     </Directory>
> > 
> > Of course, this example is already broken by doing this:
> > 
> >     GET http://abcdef:80/foo/bar
> > 
> > Or at least I think it is.
> > 
> > Perhaps we should take this time to completely blow away the "special"
> > proxy r->filename crap.  These things are URIs and should never see
> > the light of day in the filesystem code.  They're handled just fine
> > by <Location>.
> > 
> > Dean
> > 
> > On 8 Jan 1998 marc@hyperreal.org wrote:
> > 
> > > marc        98/01/07 19:56:09
> > > 
> > >   Modified:    src/main http_request.c
> > >   Log:
> > >   Move os_canonical_filename call to after the section where
> > >   !os_is_path_absolute names are dealt with to prevent bogus munging
> > >   of things like proxy:
> > >   
> > >   May(?) still cause problems with regex stuff, but fixes proxy caching
> > >   on win32.
> > >   
> > >   Reviewed by:	Ben Laurie
> > >   
> > >   Revision  Changes    Path
> > >   1.98      +1 -1      apachen/src/main/http_request.c
> > >   
> > >   Index: http_request.c
> > >   ===================================================================
> > >   RCS file: /export/home/cvs/apachen/src/main/http_request.c,v
> > >   retrieving revision 1.97
> > >   retrieving revision 1.98
> > >   diff -u -r1.97 -r1.98
> > >   --- http_request.c	1998/01/07 16:46:12	1.97
> > >   +++ http_request.c	1998/01/08 03:56:08	1.98
> > >   @@ -286,7 +286,6 @@
> > >            return OK;
> > >        }
> > >    
> > >   -    r->filename   = os_canonical_filename(r->pool, r->filename);
> > >        test_filename = pstrdup(r->pool, r->filename);
> > >    
> > >        /*
> > >   @@ -337,6 +336,7 @@
> > >            return OK;
> > >        }
> > >    
> > >   +    r->filename   = os_canonical_filename(r->pool, r->filename);
> > >        no2slash(test_filename);
> > >        num_dirs = count_dirs(test_filename);
> > >    
> > >   
> > >   
> > >   
> > > 
> > 
> 
> 
> 


Re: cvs commit: apachen/src/main http_request.c

Posted by Marc Slemko <ma...@worldgate.com>.
On Wed, 7 Jan 1998, Dean Gaudet wrote:

> This breaks stuff.  Consider:

How can it break stuff on Unix when it doesn't do anything on Unix?

If you want to argue stuff is already broken on Unix, fine, but... it
isn't broken by this change.

> 
>     GET http://abcdef/foo%2fbar
> 
> and
> 
>     <Directory proxy:http://abcdef/foo/bar>
>     ...
>     </Directory>
> 
> Of course, this example is already broken by doing this:
> 
>     GET http://abcdef:80/foo/bar
> 
> Or at least I think it is.
> 
> Perhaps we should take this time to completely blow away the "special"
> proxy r->filename crap.  These things are URIs and should never see
> the light of day in the filesystem code.  They're handled just fine
> by <Location>.
> 
> Dean
> 
> On 8 Jan 1998 marc@hyperreal.org wrote:
> 
> > marc        98/01/07 19:56:09
> > 
> >   Modified:    src/main http_request.c
> >   Log:
> >   Move os_canonical_filename call to after the section where
> >   !os_is_path_absolute names are dealt with to prevent bogus munging
> >   of things like proxy:
> >   
> >   May(?) still cause problems with regex stuff, but fixes proxy caching
> >   on win32.
> >   
> >   Reviewed by:	Ben Laurie
> >   
> >   Revision  Changes    Path
> >   1.98      +1 -1      apachen/src/main/http_request.c
> >   
> >   Index: http_request.c
> >   ===================================================================
> >   RCS file: /export/home/cvs/apachen/src/main/http_request.c,v
> >   retrieving revision 1.97
> >   retrieving revision 1.98
> >   diff -u -r1.97 -r1.98
> >   --- http_request.c	1998/01/07 16:46:12	1.97
> >   +++ http_request.c	1998/01/08 03:56:08	1.98
> >   @@ -286,7 +286,6 @@
> >            return OK;
> >        }
> >    
> >   -    r->filename   = os_canonical_filename(r->pool, r->filename);
> >        test_filename = pstrdup(r->pool, r->filename);
> >    
> >        /*
> >   @@ -337,6 +336,7 @@
> >            return OK;
> >        }
> >    
> >   +    r->filename   = os_canonical_filename(r->pool, r->filename);
> >        no2slash(test_filename);
> >        num_dirs = count_dirs(test_filename);
> >    
> >   
> >   
> >   
> > 
>