Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-announce] Jetty CVE Announcement - June 2018

Hello!


We recently released new versions for the 9.2.x, 9.3.x and 9.4.x branches. Importantly, these releases address and resolve five (5) CVEs of various severities that were recently identified. Below are summaries for each of the issues. Number 5 is easily the more critical if you are specifically using the FileSessionDataStore and an older version of Jetty 9.4.


We strongly recommend upgrading your implementation(s) as soon as possible. As always, you can find the most up-to-date versions on our Eclipse download page or on Maven Central.


We await the Mitre database to update but expect full details to populate in the near future.


1) HTTP/0.9 Request Smuggling (CVE-2017-7656)


Reported by: Régis Leroy of Makina Corpus


The Jetty HTTP/1.x Parser allows the “HTTP/0.9” version to be specified in the request line, when there is no such HTTP Version present on a valid protocol (HTTP/0.9 has no version specified).  The HTTP/0.9 code paths also allowed for Request Headers when the HTTP/0.9 protocol specifically has none. This can lead to unintended consequences with the parser, and expectations of the HTTP/0.9 client.

CVE Risk: HTTP Request Smuggling when used with invalid request headers (for HTTP/0.9) (CWE-444)

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)


Remediation:

Users of affected versions should plan upgrades based on their branch:

9.2.x - 9.2.25.v20180606 or later

9.3.x - 9.3.24.v20180605 or later

9.4.x - 9.4.11.v20180605 or later


Fixed versions will return a “400 Bad Request” response if this style of request is encountered.



2) Transfer-Encoding Request Smuggling (CVE-2017-7657)


Reported by: Régis Leroy of Makina Corpus


HTTP/1.1 Chunked Transfer-Encoding chunk sizes are handled poorly. There are 2 techniques here:
 a. Jetty only uses the last 8 bytes of the chunk size header.
 b. Jetty doesn't handle end-of-chunk properly.  

This can lead to unintended consequences with the chunked transfer-encoding parser.

CVE Risk: HTTP/1.1 Request smuggling with carefully crafted body content. (CWE-444) (Does not apply to HTTP/1.0 or HTTP/2)

Versions affected:
 All EOL releases - 9.2.x and older (all configurations)
 9.3.x (all configurations)
 9.4.x (all configurations)


Remediation:

Users of affected versions should plan upgrades based on their branch:

9.2.x - 9.2.25.v20180606 or later

9.3.x - 9.3.24.v20180605 or later

9.4.x - 9.4.11.v20180605 or later


Fixed versions will throw an org.eclipse.jetty.http.BadMessageException with status code “413 Request Entity Too Large” when this situation is encountered (typically seen when a Servlet or Filter accesses HttpServletRequest input stream).  If this exception is allowed to flow out of your Servlet, Jetty will report it to your designated Servlet spec error page handling for both status code 413 and BadMessageException.


3) Too Tolerant Parser, Double Content-Length + Transfer-Encoding + Whitespace (CVE-2017-7658)


Reported by: Régis Leroy of Makina Corpus


Double Content-Length support

When Jetty encounters a request header with more than one Content-Length header our tolerant parser attempts to figure out which one is to be used, badly. The updated RFC7230 spec makes this sort of request invalid, and Jetty shouldn't be tolerant for this kind of scenario.

The bad length parsing results in bad body parsing later.


HTTP/1.0 and HTTP/1.1 only (does not apply to HTTP/2)

Transfer-Encoding + Content-Length support

When Jetty encounters a request header with a Transfer-Encoding AND Content-Length header the tolerant parser attempts to figure out which one is to be used, badly. The updated RFC7230 spec makes this sort of request invalid, and Jetty shouldn't be tolerant for this kind of scenario.

The bad length parsing results in bad body parsing later.


HTTP/1.1 only (does not apply to HTTP/2)

Pre-Query Whitespace

When the Jetty parser encounters bad syntax related to whitespace before the request query, Jetty allows too much (according to the RFCs).


HTTP/1.0 and HTTP/1.1 only (does not apply to HTTP/2)

CVE Risk: HTTP/1.x Request Smuggling (CWE-444)

Versions affected:
 All EOL releases - 9.2.x and older (all configurations)
 9.3.x (all configurations)
 9.4.x (all configurations)


Remediation:

Users of affected versions should plan upgrades based on their branch:

9.2.x - 9.2.25.v20180606 or later

9.3.x - 9.3.24.v20180605 or later

9.4.x - 9.4.11.v20180605 or later


Fixed versions will return a “400 Bad Request” response if this style of request is encountered.

4) InvalidPathException Message (CVE-2018-12536)


Reported by: Okan Coşkun


When an intentionally bad query arrives that doesn't match a dynamic url-pattern, it is eventually handled by the DefaultServlet's static file serving. The bad characters can trigger a java.nio.file.InvalidPathException which includes the full path to the base resource directory that the DefaultServlet and/or webapp is using.


This InvalidPathException is then fed to the default Error Handler which presents the InvalidPathException message and/or stacktrace to the HTTP response. This reveals the path to the requesting system.

CVE Risk: The filesystem path to webapp is revealed. (CWE-209)

Versions affected:
 No EOL releases - 9.2.x and older (all configurations)
 9.3.x (all configurations)
 9.4.x (all configurations)


Remediation:

Users of affected versions should plan upgrades based on their branch:

9.2.x - 9.2.25.v20180606 or later

9.3.x - 9.3.24.v20180605 or later

9.4.x - 9.4.11.v20180605 or later


Fixed versions will not reveal the FileSystem specific Exceptions up to the Error Handler in code paths that use DefaultServlet or ResourceHandler.  Instead, all FileSystem related Exceptions are wrapped in a clean InvalidPathException that only reveals the URI requested path (not the entire FileSystem path)


5) FileSessionDataStore Session Hijacking (CVE-2018-12538)


Reported by: Jeffrey Morlan of Everlaw


If using the optional Jetty provided FileSessionDataStore for persistent storage of HttpSession details, it is possible for a malicious user to access/hijack other HttpSessions and even delete unmatched HttpSessions present in the FileSystem’s storage for the FileSessionDataStore.


The use of partial Session IDs can result in the hijacking of an existing HttpSession, as well as the deletion of other HttpSessions that also match this partial SessionID.


A partial Session ID of a single byte could be used to access a random users HttpSession with that single byte match, including the deletion of other HttpSessions that match that single byte.


A partial Session ID of blank could result in the return of the most recent HttpSession and deletion of all stored HttpSessions.


This vulnerability was corrected in Jetty 9.4.9 with a complete overhaul of the FileSessionDataStore with an eye on the performance of large lists of HttpSessions.  This vulnerability was not known at the time the 9.4.9 fix was being implemented.



CVE Risk: HttpSessions present specifically in the FileSystem’s storage could be hijacked/accessed by an unauthorized user.  (CWE-200) HttpSessions present in the FileSystems’ storage could be deleted by an unauthorized user.


Versions Affected:

9.4.0.v20161208

9.4.1.v20170120

9.4.2.v20170220

9.4.3.v20170317

9.4.4.v20170414

9.4.5.v20170502

9.4.6.v20170531

9.4.7.v2017094

9.4.8.v20171121


Configurations Affected:

Only configurations using the org.eclipse.jetty.server.session.FileSessionDataStore class are impacted.

Users of jetty-distribution / jetty-home with the session-store-file module are also impacted.


Remediation:

Users/Implementations affected by this issue are strongly encouraged to upgrade to 9.4.11.v20180605, as it also includes the fixes for the other CVEs reported earlier.


For users that cannot upgrade to 9.4.11.v20180605 immediately and feel they are adequately protected from the other CVEs discussed above, we have built out new, patched versions of the above-affected versions of Jetty to backport (only) the FileSessionDataStore vulnerability for impacted and problematic versions. These patched versions can be downloaded from Maven Central and follow a naming convention of 9.4.[0-8].v20180619.


Fixed versions are more strict on how Requested Session ID relates to the generated Session ID on the FileSystem.


Note: The FileSessionDataStore is one of many optional configurations for Session persistence.  All other session persistence configurations (memory, jdbc, nosql, infinispan, gcloud, etc) are safe, and unaffected by this vulnerability.


Commercial production and development support for Jetty is offered through Webtide (www.webtide.com). Please contact us for more information or email jesse@xxxxxxxxxxx to discuss your specific needs.


Best Regards,

The Jetty Development Team



Back to the top