Community
Participate
Working Groups
HTTP/0.9 is handled poorly. We expected the version when there shouldn't have been one. We parsed headers when there shouldn't have been any. This can lead to unintended consequences with our parser. CVE Risk: Request Smuggling when used with Range header Versions affected: All EOL releases - 9.2.x and older (all configurations) 9.3.x (all configurations) 9.4.x (non-default configuration with RFC2616 compliance enabled) Resolved: 9.3.24.v20180605 9.4.11.v20180605
A HTTP/1 style request line (ie method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. Specifically the response was sent without any headers. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response. The chain of events needed for an exploit makes this an unlikely scenario, but with significant possible impact if achieved.
Discovered and reported by Régis Leroy <regis.leroy@makina-corpus.com>
Does this description sound about right? "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), HTTP/0.9 is handled poorly. A HTTP/1 style request line (ie method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response."
There's 2 flaws. The first is that someone could give us the version identifier for HTTP/0.9 (that simply doesn't exist in a spec, and should not be present in the request line) > GET /resource HTTP/0.9 The next one is that our parser accepted request headers in HTTP/0.9 mode. eg: > GET /resource > Byte-Range: 5-40 but HTTP/0.9 spec has no request headers. So that's also bad. I think your text covers the first one rather well, but seems to be missing the request headers portion.
I think Wayne's text covers the CVE nature of this issue well. The fact that we have a bug about accepting 0.9 is incidental as while it should be fixed there is no security implications. So I think the text is good.
> CVE Risk: Request Smuggling when used with Range header Does this look like the right CWE? https://cwe.mitre.org/data/definitions/444.html
That CWE describes the issue in general, but its specific examples are very much related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=535669 and less so to https://bugs.eclipse.org/bugs/show_bug.cgi?id=535668 But in general, it is a reasonable description of the problem
Wayne, do we need to create CVSS numbers for these issues?
(In reply to Jesse McConnell from comment #8) > Wayne, do we need to create CVSS numbers for these issues? No. We don't push them upstream. More of a nice to have.
Pull request: https://github.com/CVEProject/cvelist/pull/648
where can id download?
