Bugzilla – Full Text Bug Listing
| Summary: | Jetty: CVE Request: Too Tolerant Parser, Double Content-Length + Transfer-Encoding + Whitespace | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Jesse McConnell <jesse.mcconnell> | ||||||
| Component: | Vulnerability Reports | Assignee: | Security vulnerabilitied reported against Eclipse projects <vulnerability.reports-inbox> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | 1040972695, 1137964313, 1143502142, 1175542797, 12349685, 1500783394, 1535185308, 1546976352, 296967843, 507710564, 615071883, 905032473, canyueduyi, ctwalker, d18515002805, dchavefun, esonyouth2012, gregw, jiqiaowang, jmnbv1, john.zhao, king_201314, lwh1727, q405839925, wayne.beaton | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jesse McConnell
Discovered and reported by Régis Leroy <regis.leroy@makina-corpus.com> When presented with two content-lengths headers, jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If deployed behind an intermediary that interpreted these headers differently, but still passed on the request headers unchanged, then it would be possible for the intermediary and jetty to disagree on the body length. If the intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by jetty as a pipelined requests. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization. An exploit would need a very particular intermediary behaviour and is thus very unlikely. However, if achieved an exploit would have serious consequences as authorization would be bypassed How does this 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), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined requests. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization." Lgtm "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), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined requests. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization." This one also impacts HTTP/1.0 and HTTP/1.1 users, but not HTTP/2 users. Perhaps the first section could read ... "In Eclipse Jetty Server, versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), when presented with two content-lengths headers, Jetty ignored the second." Note change to "Eclipse Jetty Server" (as we also have an Eclipse Jetty Client). Should probably clean up that language for the other CVEs too. > CVE Risk: Request Smuggling Is this CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')? https://cwe.mitre.org/data/definitions/444.html yes for CWE 444 Pull request: https://github.com/CVEProject/cvelist/pull/650 Created attachment 284959 [details]
111
在哪里下载补丁呀？ 补丁在哪下载？ Just upgrade the version of Jetty you are using to someone with the issue resolved, there is no specific patch for arbitrary versions of Jetty you might be using. Comment on attachment 284959 [details]
111
fdsaf
Download the patch there (In reply to Jesse McConnell from comment #0) > Double Content-Length support > > When we encounter a request header with more then 1 Content-Length header > our tolerant parse attempts to figure out which one is to be used, badly. > > The updated RFC7230 spec makes this kind of request invalid, and we > shouldn't be tolerant for this kind of scenario. > > The bad length parsing results in bad body parsing later. > > Transfer-Encoding + Content-Length support > > When we encounter a request header with a Transfer-Encoding AND > Content-Length header our tolerant parse attempts to figure out which one is > to be used, badly. > > The updated RFC7230 spec makes this kind of request invalid, and we > shouldn't be tolerant for this kind of scenario. > > The bad length parsing results in bad body parsing later. > > > Pre-Query Whitespace > > When our parser encounters bad syntax related to whitespace before the > request query we allow too much (according to the RFCs) > > CVE Risk: Request Smuggling > > Versions affected: > All EOL releases - 9.2.x and older (all configurations) > 9.3.x (all configurations) > 9.4.x (all configurations) > > Resolved: > 9.2.25.v20180606 > 9.3.24.v20180605 > 9.4.11.v20180605 Created attachment 287656 [details]
Eclipse Jetty HTTP请求走私漏洞（CVE-2017-7658）
Comment on attachment 284959 [details] 111 >×¢²áÂë >101210-450789-147200 Comment on attachment 284959 [details] 111 >×¢²áÂë >101210-450789-147200 Comment on attachment 284959 [details] 111 >×¢²áÂë >101210-450789-147200 Comment on attachment 284959 [details] 111 >×¢²áÂë >101210-450789-147200 The content of attachment 287656 [details] has been deleted for the following reason:
spam attachment
The content of attachment 284959 [details] has been deleted for the following reason:
spam attachment
|