Community
Participate
Working Groups
transfer-encoding chunks handled poorly There are 2 techniques here. a. We only parse the last 8 bytes of the chunk size header. b. We don't handle end-of-chunk properly. This can lead to unintended consequences with our chunked transfer-encoding parser CVE Risk: Request smuggling with carefully crafted body content Versions affected: All EOL releases - 9.2.x and older (all configurations) 9.3.x (all configurations) 9.4.x (all configurations) Resolved: 9.3.24.v20180605 9.4.11.v20180605
Discovered and reported by Régis Leroy <regis.leroy@makina-corpus.com>
The chunk length parsing was vulnerable to a integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request. An exploit required a rather specific circumstance of intermediary behaviour, so is unlikely. However the impact of any exploit could be large as authorization is bypassed.
How does this summary sound? "In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to a integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request."
> In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to a integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request. Drop the "(non-default configuration with RFC2616 compliance enabled)" piece. This impacts people using HTTP/1.1 only (not HTTP/1.0 or HTTP/2), so perhaps the first portion could read as ... > In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all HTTP/1.1 configurations), and 9.4.x (all HTTP/1.1 configurations), transfer-encoding chunks are handled poorly. ?
Lgtm
> CVE Risk: Request smuggling with carefully crafted body content This looks like CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') https://cwe.mitre.org/data/definitions/444.html Make sense?
yes for CWE-444
Wayne, is it possible to put a hold on releasing the text on this on for a few days? There is something we want to investigate a bit further on this one specifically.
(In reply to Jesse McConnell from comment #8) > Wayne, is it possible to put a hold on releasing the text on this on for a > few days? There is something we want to investigate a bit further on this > one specifically. Let me know when you're ready to move this forward.
Wayne, Our current plan is to announce the CVEs all on this next Monday to the mailing lists as we coordinate a number of things. We would like to see this issue and #536018 be prepared and ready to be released publically on Monday as well. The other three issues we are happy to see go public at your schedule. I am going to post in #536018 some updates now but I wanted to give you a heads up. Please let us know if this doesn't work for you! cheers, Jesse
Pull request: https://github.com/CVEProject/cvelist/pull/649