Update dependency org.eclipse.jetty:jetty-server to v9.4.51.v20230217 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.eclipse.jetty:jetty-server (source)	9.2.3.v20140905 -> 9.4.51.v20230217

GitHub Vulnerability Alerts

CVE-2021-34428

Impact

If an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID manager. On deployments with clustered sessions and multiple contexts this can result in a session not being invalidated. This can result in an application used on a shared computer being left logged in.

There is no known path for an attacker to induce such an exception to be thrown, thus they must rely on an application to throw such an exception. The OP has also identified that during the call to sessionDestroyed, the getLastAccessedTime() throws an IllegalStateException, which potentially contrary to the servlet spec, so applications calling this method may always throw and fail to log out. If such an application was only tested on a non clustered test environment, then it may be deployed on a clustered environment with multiple contexts and fail to log out.

Workarounds

The application should catch all Throwables within their SessionListener#sessionDestroyed() implementations.

CVE-2017-7658

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), are vulnerable to HTTP Request Smuggling when presented with two content-lengths headers, allowing authorization bypass. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decides on the shorter length, but still passes on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermediary is imposing authorization, the fake pipelined request bypasses that authorization.

CVE-2023-26048

Impact

Servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and a very large content.

This happens even with the default settings of fileSizeThreshold=0 which should stream the whole part content to disk.

An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError.
However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time.

A very large number of parts may cause the same problem.

Patches

Patched in Jetty versions

• 9.4.51.v20230217 - via PR #​9345
• 10.0.14 - via PR #​9344
• 11.0.14 - via PR #​9344

Workarounds

Multipart parameter maxRequestSize must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).
Limiting multipart parameter maxFileSize won't be enough because an attacker can send a large number of parts that summed up will cause memory issues.

References

• https://github.com/eclipse/jetty.project/issues/9076
• https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload

CVE-2023-26049

Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism.

If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered.

So, a cookie header such as:

DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d

instead of 3 separate cookies.

Impact

This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server.

Patches

• 9.4.51.v20230217 - via PR #​9352
• 10.0.15 - via PR #​9339
• 11.0.15 - via PR #​9339

Workarounds

No workarounds

References

• https://www.rfc-editor.org/rfc/rfc2965
• https://www.rfc-editor.org/rfc/rfc6265

CVE-2019-10247

In Eclipse Jetty version 7.x, 8.x, 9.2.27 and older, 9.3.26 and older, and 9.4.16 and older, the server running on any OS and Jetty version combination will reveal the configured fully qualified directory base resource location on the output of the 404 error for not finding a Context that matches the requested path. The default server behavior on jetty-distribution and jetty-home will include at the end of the Handler tree a DefaultHandler, which is responsible for reporting this 404 error, it presents the various configured contexts as HTML for users to click through to. This produced HTML includes output that contains the configured fully qualified directory base resource location for each context.

CVE-2019-10246

In Eclipse Jetty version 9.2.27, 9.3.26, and 9.4.16, the server running on Windows is vulnerable to exposure of the fully qualified Base Resource directory name on Windows to a remote client when it is configured for showing a Listing of directory contents. This information reveal is restricted to only the content in the configured base resource directories.

CVE-2019-10241

In Eclipse Jetty version 9.2.26 and older, 9.3.25 and older, and 9.4.15 and older, the server is vulnerable to XSS conditions if a remote client USES a specially formatted URL against the DefaultServlet or ResourceHandler that is configured for showing a Listing of directory contents.

CVE-2017-7657

In Eclipse Jetty, versions 9.2.x and older, 9.3.x, 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-2015-2080

The exception handling code in Eclipse Jetty prior to 9.2.9.v20150224 allows remote attackers to obtain sensitive information from process memory via illegal characters in an HTTP header, aka JetLeak.

CVE-2017-7656

Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), contain an HTTP Request Smuggling Vulnerability that can result in cache poisoning.

CVE-2017-9735

Jetty through 9.4.x contains a timing channel attack in util/security/Password.java, which allows attackers to obtain access by observing elapsed times before rejection of incorrect passwords.

CVE-2018-12536

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.

CVE-2021-28165

Impact

When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage.

Workarounds

The problem can be worked around by compiling the following class:

package org.eclipse.jetty.server.ssl.fix6072;

import java.nio.ByteBuffer;
import javax.net.ssl.SSLEngine;
import javax.net.ssl.SSLEngineResult;
import javax.net.ssl.SSLException;
import javax.net.ssl.SSLHandshakeException;

import org.eclipse.jetty.io.EndPoint;
import org.eclipse.jetty.io.ssl.SslConnection;
import org.eclipse.jetty.server.Connector;
import org.eclipse.jetty.server.SslConnectionFactory;
import org.eclipse.jetty.util.BufferUtil;
import org.eclipse.jetty.util.annotation.Name;
import org.eclipse.jetty.util.ssl.SslContextFactory;

public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory
{
    public SpaceCheckingSslConnectionFactory(@​Name("sslContextFactory") SslContextFactory factory, @​Name("next") String nextProtocol)
    {
        super(factory, nextProtocol);
    }

    @​Override
    protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine)
    {
        return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption())
        {
            @​Override
            protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException
            {
                SSLEngineResult results = super.unwrap(sslEngine, input, output);

                if ((results.getStatus() == SSLEngineResult.Status.BUFFER_UNDERFLOW ||
                    results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) &&
                    BufferUtil.space(input) == 0)
                {
                    BufferUtil.clear(input);
                    throw new SSLHandshakeException("Encrypted buffer max length exceeded");
                }
                return results;
            }
        };
    }
}

This class can be deployed by:

• The resulting class file should be put into a jar file (eg sslfix6072.jar)
• The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib
• Copy the file ${jetty.home}/modules/ssl.mod to ${jetty.base}/modules
• Edit the ${jetty.base}/modules/ssl.mod file to have the following section:

[lib]
lib/sslfix6072.jar

• Copy the file ${jetty.home}/etc/jetty-https.xml and${jetty.home}/etc/jetty-http2.xml to ${jetty.base}/etc
• Edit files ${jetty.base}/etc/jetty-https.xml and ${jetty.base}/etc/jetty-http2.xml, changing any reference of org.eclipse.jetty.server.SslConnectionFactory to org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory. For example:

  <Call name="addIfAbsentConnectionFactory">
    <Arg>
      <New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory">
        <Arg name="next">http/1.1</Arg>
        <Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg>
      </New>
    </Arg>
  </Call>

• Restart Jetty

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.