fix(deps): 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.4.15.v20190215 -> 9.4.51.v20230217

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

GitHub Vulnerability Alerts

CVE-2020-27218

Impact

If GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection and if an
attacker can send a request with a body that is received entirely by not consumed by the application, then a subsequent request
on the same connection will see that body prepended to it's body.

The attacker will not see any data, but may inject data into the body of the subsequent request

CVE score is 4.8 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Workarounds

The problem can be worked around by either:

• Disabling compressed request body inflation by GzipHandler.
• By always fully consuming the request content before sending a response.
• By adding a Connection: close to any response where the servlet does not fully consume request content.

CVE-2020-27223

Impact

When Jetty handles a request containing request headers with a large number of “quality” (i.e. q) parameters (such as what are seen on the Accept, Accept-Encoding, and Accept-Language request headers), the server may enter a denial of service (DoS) state due to high CPU usage while sorting the list of values based on their quality values. A single request can easily consume minutes of CPU time before it is even dispatched to the application.

The only features within Jetty that can trigger this behavior are:

• Default Error Handling - the Accept request header with the QuotedQualityCSV is used to determine what kind of content to send back to the client (html, text, json, xml, etc)
• StatisticsServlet - uses the Accept request header with the QuotedQualityCSV to determine what kind of content to send back to the client (xml, json, text, html, etc)
• HttpServletRequest.getLocale() - uses the Accept-Language request header with the QuotedQualityCSV to determine which “preferred” language is returned on this call.
• HttpservletRequest.getLocales() - is similar to the above, but returns an ordered list of locales based on the quality values on the Accept-Language request header.
• DefaultServlet - uses the Accept-Encoding request header with the QuotedQualityCSV to determine which kind of pre-compressed content should be sent back for static content (content that is not matched against a url-pattern in your web app)

Versions

QuotedQualityCSV was introduced to Jetty 9.3.9.v20160517 and the bug that introduced the vulnerability was in 9.4.6.v20170531.

Currently, known vulnerable versions include:

• 9.4.6.v20170531 thru to 9.4.36.v20210114
• 10.0.0
• 11.0.0

Workarounds

Quality ordered values are used infrequently by jetty so they can be avoided by:

• Do not use the default error page/handler.
• Do not deploy the StatisticsServlet exposed to the network
• Do not call getLocale API
• Do not enable precompressed static content in the DefaultServlet

Patches

All patches are available for download from the Eclipse Jetty website at https://www.eclipse.org/jetty/download.php

• 9.4.37.v20210219 and greater
• 10.0.1 and greater
• 11.0.1 and greater

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-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-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-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 has been generated by Mend Renovate. View repository job log here.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication