On Thu, Sep 24, 2020 at 2:11 PM Martin Grigorov <mgrigo...@apache.org> wrote:
> Hi, > > On Thu, Sep 24, 2020 at 1:02 PM Nils Breunese <n...@breun.nl> wrote: > >> Hello, >> >> I recently learned that when a server that supports path parameters [0] — >> like Tomcat (I found Jetty also does) — is run behind a reverse proxy that >> does path-based access control checks and does not support path parameters, >> your combined setup could be vulnerable. >> >> Consider this setup: >> >> 1. A Tomcat application without access restrictions >> 2. An reverse proxy that only allows requests to /v1/* on the Tomcat >> application. I’ve used Envoy on Kubernetes, configured via Istio’s >> Role-Based Access Control (RBAC), but also observed this issue with other >> proxies. >> >> Now I send a request for /v1/..;color=red/internal/secret to the proxy. >> >> - Envoy allows the request based on the /v1/* rule, because it does not >> support path parameters, because they are not part of any recent standard >> (RFC 2396 dropped them in 1998 [1]) >> - Tomcat parses ;color=red as a path parameter, resolves the rest of the >> path to /v1/../internal/secret and consequently serves /internal/secret >> - I’m pretty sure that whoever configured that RBAC policy did not want >> this to be possible >> >> Note that: >> - The client can request any URL on the Tomcat server via this path >> traversal attack. >> - This also works with ‘empty’ path parameters, e.g. >> /v1/..;/internal/secret >> - The URL doesn’t necessarily need to contain ‘..’ for naughtiness to be >> possible. When access to /public/secret would be restricted by the proxy, >> but other /public/* paths would be allowed, then an attacker would still be >> able to get the contents of /public/secret by requesting /public;/secret >> >> The fact that different servers handle paths with path parameters >> differently seems to be known [2], but especially setups in which reverse >> proxies don’t support path parameters, but the servers behind them do, >> seems risky. >> >> Would it be reasonable to create a ticket with a feature request for a >> flag to disable path parameter support in Tomcat? Or an even more secure >> suggestion: make path parameter support an opt-in feature, because it was >> dropped from the URI standard in 1998 and can make setups like I described >> vulnerable? >> > > I remember a similar discussion from a few months ago. > Which version of Tomcat do you use ? Please try with the latest in case > you use an older one. > I've just checked my mail archives. Someone else had the same/similar problem and the conclusion was that according to the Servlet specification this is the proper way to process the request - the request url should be normalized. If you need to protect some paths then you should do whatever is necessary in your application. Please use secur...@tomcat.apache.org for reporting (possible) security problems in the future! Thanks! Martin > > >> >> Thanks, Nils. >> >> [0] RFC 1738 https://tools.ietf.org/html/rfc1738 < >> https://tools.ietf.org/html/rfc1738> (1994) and RFC 1808 >> https://tools.ietf.org/html/rfc1808 <https://tools.ietf.org/html/rfc1808> >> (1995). >> [1] RFC 2396 G.4. Modifications from RFC 1808 >> https://tools.ietf.org/html/rfc2396 <https://tools.ietf.org/html/rfc2396> >> (1998). Path parameters are also absent in RFC 3986 >> https://tools.ietf.org/html/rfc3986 <https://tools.ietf.org/html/rfc3986> >> (2005). >> [2] >> https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf >> < >> https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf> >> slides 41 and further > >
