Update dependency org.eclipse.jetty:jetty-server to v11.0.24 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
org.eclipse.jetty:jetty-server (source)	11.0.6 → 11.0.24

GitHub Vulnerability Alerts

CVE-2022-2191

Impact

SslConnection does not release ByteBuffers in case of error code paths.
For example, TLS handshakes that require client-auth with clients that send expired certificates will trigger a TLS handshake errors and the ByteBuffers used to process the TLS handshake will be leaked.

Workarounds

Configure explicitly a RetainableByteBufferPool with max[Heap|Direct]Memory to limit the amount of memory that is leaked.
Eventually the pool will be full of "active" entries (the leaked ones) and will provide ByteBuffers that will be GCed normally.

With embedded-jetty

int maxBucketSize = 1000;
long maxHeapMemory = 128 * 1024L * 1024L; // 128 MB
long maxDirectMemory = 128 * 1024L * 1024L; // 128 MB
RetainableByteBufferPool rbbp = new ArrayRetainableByteBufferPool(0, -1, -1, maxBucketSize, maxHeapMemory, maxDirectMemory);

server.addBean(rbbp); // make sure the ArrayRetainableByteBufferPool is added before the server is started
server.start();

With jetty-home/jetty-base

Create a ${jetty.base}/etc/retainable-byte-buffer-config.xml

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "https://www.eclipse.org/jetty/configure_10_0.dtd">

<Configure id="Server" class="org.eclipse.jetty.server.Server">
  <Call name="addBean">
    <Arg>
      <New class="org.eclipse.jetty.io.ArrayRetainableByteBufferPool">
        <Arg type="int"><Property name="jetty.byteBufferPool.minCapacity" default="0"/></Arg>
        <Arg type="int"><Property name="jetty.byteBufferPool.factor" default="-1"/></Arg>
        <Arg type="int"><Property name="jetty.byteBufferPool.maxCapacity" default="-1"/></Arg>
        <Arg type="int"><Property name="jetty.byteBufferPool.maxBucketSize" default="1000"/></Arg>
        <Arg type="long"><Property name="jetty.byteBufferPool.maxHeapMemory" default="128000000"/></Arg>
        <Arg type="long"><Property name="jetty.byteBufferPool.maxDirectMemory" default="128000000"/></Arg>
      </New>
    </Arg>
  </Call>
</Configure>

And then reference it in ${jetty.base}/start.d/retainable-byte-buffer-config.ini

etc/retainable-byte-buffer-config.xml

References

https://github.com/eclipse/jetty.project/issues/8161

For more information

• Email us at security@webtide.com

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-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-2024-8184

Impact

Remote DOS attack can cause out of memory

Description

There exists a security vulnerability in Jetty's ThreadLimitHandler.getRemote() which
can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By
repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the
server's memory.

Affected Versions

• Jetty 12.0.0-12.0.8 (Supported)
• Jetty 11.0.0-11.0.23 (EOL)
• Jetty 10.0.0-10.0.23 (EOL)
• Jetty 9.3.12-9.4.55 (EOL)

Patched Versions

• Jetty 12.0.9
• Jetty 11.0.24
• Jetty 10.0.24
• Jetty 9.4.56

Workarounds

Do not use ThreadLimitHandler.
Consider use of QoSHandler instead to artificially limit resource utilization.

References

Jetty 12 - https://github.com/jetty/jetty.project/pull/11723

---

Configuration

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

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, 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.