This Bugzilla instance closed for new bug entry. Eclipse projects now use GitHub or Eclipse GitLab. Please locate your project of interest with the Projects search tool to find the best location for that project's code and issues.
Bug 535668 (CVE-2017-7657) - Jetty: CVE Request: Transfer-Encoding Request Smuggling
Summary: Jetty: CVE Request: Transfer-Encoding Request Smuggling
Status: CLOSED FIXED
Alias: CVE-2017-7657
Product: Community
Classification: Eclipse Foundation
Component: Vulnerability Reports (show other bugs)
Version: unspecified   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Security vulnerabilitied reported against Eclipse projects CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-07 15:33 EDT by Jesse McConnell CLA
Modified: 2024-10-22 02:45 EDT (History)
19 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse McConnell CLA 2018-06-07 15:33:59 EDT
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
Comment 1 Greg Wilkins CLA 2018-06-08 04:08:57 EDT
Discovered and reported by Régis Leroy <regis.leroy@makina-corpus.com>
Comment 2 Greg Wilkins CLA 2018-06-08 04:13:06 EDT
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.
Comment 3 Wayne Beaton CLA 2018-06-18 13:19:40 EDT
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."
Comment 4 Joakim Erdfelt CLA 2018-06-18 13:59:48 EDT
> 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.

?
Comment 5 Greg Wilkins CLA 2018-06-18 14:00:50 EDT
Lgtm
Comment 6 Wayne Beaton CLA 2018-06-18 14:39:53 EDT
> 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?
Comment 7 Greg Wilkins CLA 2018-06-18 17:05:54 EDT
yes for CWE-444
Comment 8 Jesse McConnell CLA 2018-06-18 18:14:34 EDT
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.
Comment 9 Wayne Beaton CLA 2018-06-18 22:51:02 EDT
(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.
Comment 10 Jesse McConnell CLA 2018-06-19 13:21:18 EDT
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
Comment 11 Wayne Beaton CLA 2018-06-26 10:51:16 EDT
Pull request: https://github.com/CVEProject/cvelist/pull/649