tree 6d4905665e8e89bfcfb9f9e0093dfbbac92cd2a9
parent 6f97ef16b34c1fd1d22bfcc8e2720c22a209600c
author David Pursehouse <dpursehouse@collab.net> 1541120210 +0900
committer David Pursehouse <dpursehouse@collab.net> 1541379640 +0900

Upgrade Jetty to 9.3.24.v20180605 to fix several CVEs

This upgrade fixes the following CVEs:

- CVE-2017-7656 [1]:

  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. An HTTP/1 style request line (i.e. 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.

- CVE-2017-7657 [2]:

  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 an 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.

- CVE-2017-7658 [3]:

  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-length 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 request. If the intermediary was imposing authorization, the fake
  pipelined request would bypass that authorization.

- CVE-2017-9735 [4]:

  Jetty through 9.4.x is prone to a timing channel in util/security/Password.java,
  which makes it easier for remote attackers to obtain access by observing
  elapsed times before rejection of incorrect passwords.

- CVE-2018-12536 [5]:

  In Eclipse Jetty Server, all 9.x versions, on webapps deployed using default
  Error Handling, when an intentionally bad query arrives that doesn't match a
  dynamic url-pattern, and 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. If this
  InvalidPathException is then handled by the default Error Handler, the
  InvalidPathException message is included in the error response, revealing the
  full server path to the requesting system.

[1] https://nvd.nist.gov/vuln/detail/CVE-2017-7656
[2] https://nvd.nist.gov/vuln/detail/CVE-2017-7657
[3] https://nvd.nist.gov/vuln/detail/CVE-2017-7658
[4] https://nvd.nist.gov/vuln/detail/CVE-2017-9735
[5] https://nvd.nist.gov/vuln/detail/CVE-2018-12536

Bug: Issue 9952
Change-Id: I1ebb91406b88289e3803ffb1d5049ea7352c695c