Update dependency org.eclipse.jetty:jetty-server to v11.0.24 [SECURITY] #49
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
11.0.6
->11.0.24
GitHub Vulnerability Alerts
CVE-2022-2191
Impact
SslConnection
does not releaseByteBuffer
s 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
ByteBuffer
s used to process the TLS handshake will be leaked.Workarounds
Configure explicitly a
RetainableByteBufferPool
withmax[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
ByteBuffer
s that will be GCed normally.With embedded-jetty
With jetty-home/jetty-base
Create a
${jetty.base}/etc/retainable-byte-buffer-config.xml
And then reference it in
${jetty.base}/start.d/retainable-byte-buffer-config.ini
References
https://github.com/eclipse/jetty.project/issues/8161
For more information
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 nameDISPLAY_LANGUAGE
and a value ofb; JSESSIONID=1337; c=d
instead of 3 separate cookies.
Impact
This has security implications because if, say,
JSESSIONID
is anHttpOnly
cookie, and theDISPLAY_LANGUAGE
cookie value is rendered on the page, an attacker can smuggle theJSESSIONID
cookie into theDISPLAY_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
Workarounds
No workarounds
References
CVE-2023-26048
Impact
Servlets with multipart support (e.g. annotated with
@MultipartConfig
) that callHttpServletRequest.getParameter()
orHttpServletRequest.getParts()
may causeOutOfMemoryError
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
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
CVE-2024-8184
Impact
Remote DOS attack can cause out of memory
Description
There exists a security vulnerability in Jetty's
ThreadLimitHandler.getRemote()
whichcan 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
Patched Versions
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.
This PR was generated by Mend Renovate. View the repository job log.