Chris Walker
2018-06-25 16:17:08 UTC
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 <https://www.eclipse.org/jetty/download.html> or on Maven
Central <http://central.maven.org/maven2/org/eclipse/jetty/>.
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 <https://cwe.mitre.org/data/definitions/444.html>)
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 <https://cwe.mitre.org/data/definitions/444.html>) (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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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
<https://cwe.mitre.org/data/definitions/444.html>)
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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
<https://cwe.mitre.org/data/definitions/209.html>)
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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
<https://cwe.mitre.org/data/definitions/200.html>) 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 <http://central.maven.org/maven2/org/eclipse/jetty/> 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 <https://webtide.com/contact/>
for more information or email ***@webtide.com to discuss your specific
needs.
Best Regards,
The Jetty Development Team
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 <https://www.eclipse.org/jetty/download.html> or on Maven
Central <http://central.maven.org/maven2/org/eclipse/jetty/>.
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 <https://cwe.mitre.org/data/definitions/444.html>)
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 <https://cwe.mitre.org/data/definitions/444.html>) (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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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
<https://cwe.mitre.org/data/definitions/444.html>)
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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
<https://cwe.mitre.org/data/definitions/209.html>)
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
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=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
<https://cwe.mitre.org/data/definitions/200.html>) 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 <http://central.maven.org/maven2/org/eclipse/jetty/> 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 <https://webtide.com/contact/>
for more information or email ***@webtide.com to discuss your specific
needs.
Best Regards,
The Jetty Development Team