tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Frederic <jfcl...@gmail.com>
Subject Re: Improving mod_jk URI forwarding
Date Sun, 20 May 2007 17:31:13 GMT
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
> Before I answer, let me first ask a question: What's wrong withg my 
> suggestion? Or even better: use the encoding done with mod_proxy_ajp?

For me there is nothing wrong except it adds 2 JKoptions or 3 :-)

We know that Tomcat is going to normalise a url we have already
normalised. Shouldn't we check that a second normalisation (like the
Tomcat one) gives a different url and if yes have a flag to return
"forbidden"? (Yes that would be a 4th option).

Cheers

Jean-Frederic

>
> >> Original URI:
> >>
> >> /myapp/%252e%252e/otherapp/danger
> >>
> >> JkMount /myapp/*
> >>
> >> Apache httpd will correctly decode the URI to
> >>
> >> /myapp/%2e%2e/otherapp/danger
> >>
> >> mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.
> >>
> > 
> > It does not IMO, and that's what I'm talking.
> > Inside mod_jk we should decode
> > /myapp/%2e%2e/otherapp/danger to
> > /myapp/../otherapp/danger
> 
> No, If the original URI was /myapp/%252e%252e/otherapp/danger, then it 
> is not correct to end up with /otherapp/danger as a decoded URL. A 
> percent sign is a valid character in a ressource path. If one wants to 
> use it in ressource paths, one needs to encode it ('%25'), and it is not 
> allowed to decode '%25XX' again after decoding to '%XX' once.
> 
> So %252e -> %2e and that's it, no further decoding. It is not a '.', 
> because it is decoded already.
> 
> Why do you think, that
> 
> /myapp/%252e%252e/otherapp/danger
> 
> is equivalent to
> 
> /myapp/../otherapp/danger ?
> 
> > Do a normalization of the uri that will end up as
> > /otherapp/danger before hitting map_uri_to_worker
> > If there is no JkMount for /otherapp/ it will be
> > denied, if it is, the rewritten uri /otherapp/danger
> > will be send instead /myapp/%2e%2e/otherapp/danger.
> > Of course we can simply send /myapp/%2e%2e/otherapp/danger
> > to tomcat if the match is OK for /otherapp/,
> > and let the tomcat do a normalization once again.
> 
> As I said, double decoding ("again") is not allowed and is the source of 
> all evil.
> 
> > In that case we won't need to encode the normalized
> > uri inside mod_jk once more.
> 
> I'm sure we need to, because double encoding is not allowed, but Tomcat 
> unfortunately does a second decoding.
> 
> Some evidence:
> 
> 0) RFC 2396, RFC 3986
> =====================
> 
> http://www.ietf.org/rfc/rfc2396.txt
> 
> Section 2.4.2. When to Escape and Unescape:
> 
> "Implementers should be careful not to
>     escape or unescape the same string more than once, since unescaping
>     an already unescaped string might lead to misinterpreting a percent
>     data character as another escaped character, or vice versa in the
>     case of escaping an already escaped string."
> 
> and even stricter the younger
> 
> http://tools.ietf.org/html/rfc3986
> 
> 2.4. When to Encode or Decode
> 
> "Implementations must not
>     percent-encode or decode the same string more than once, as decoding
>     an already decoded string might lead to misinterpreting a percent
>     data octet as the beginning of a percent-encoding, or vice versa in
>     the case of percent-encoding an already percent-encoded string."
> 
> 1) IIS Bug
> ==========
> 
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0333
> 
> which leads to
> 
> http://www.microsoft.com/technet/security/Bulletin/MS01-026.mspx
> 
> "What's wrong with the decoding operation?
> There's nothing wrong with the decoding operation per se. The 
> vulnerability results because, through an implementation flaw, the 
> decoding operation is performed a second time, after the security checks 
> on the request have been completed."
> 
> 2) mod_security Bug
> ===================
> 
> http://www.modsecurity.org/download/CHANGES
> 
> "BUG Fixed a double URL-decoding bug (Apache first, then us), which
>      could sometimes lead to a false positive."
> 
> 3) DAV Bugs
> ===========
> 
> http://dav.sourceforge.net/
> 
> "The following bugs should have gone:
> 
>      * [ 1519718 ] davfs2 fails to properly decode complex escape sequences
>      * [ 1522903 ] chokes on directory names containing ' _ % characters
>      * [ 1539444 ] mounting of webdav drive fails
>      * [ 1539445 ] unable to access files in mounted webdav drive
>      * [ 1558525 ] davfs2-1.0.2_p20060820 mount fails
> 
> These bugs were related to ... and incorrect double url-decoding of urls."
> 
> Regards,
> 
> Rainer
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message