Search for packages
| purl | pkg:maven/org.eclipse.jetty/jetty-server@11.0.3 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-9xw3-4a4u-hbbb
Aliases: CVE-2023-26049 GHSA-p26g-97m4-6q7c |
Exposure of Sensitive Information to an Unauthorized Actor Jetty is a java based web server and servlet engine. 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. 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 or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue. |
Affected by 1 other vulnerability. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-h3wz-rdkt-7ue6
Aliases: CVE-2022-2191 GHSA-8mpp-f3f7-xc28 |
Jetty SslConnection does not release pooled ByteBuffers in case of errors ### Impact `SslConnection` does not release `ByteBuffer`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` 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 `ByteBuffer`s that will be GCed normally. _With embedded-jetty_ ``` java 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 <?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](mailto:security@webtide.com) |
Affected by 3 other vulnerabilities. |
|
VCID-q3k2-1x5q-buhy
Aliases: CVE-2023-40167 GHSA-hmr7-m48g-48f6 |
Improper Handling of Length Parameter Inconsistency Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-y3mv-vmwd-tydt
Aliases: CVE-2023-26048 GHSA-qw69-rqj8-6qw8 |
False positive This vulnerability has been marked as a false positive. |
Affected by 1 other vulnerability. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-q35p-8qhp-aqec | SessionListener can prevent a session from being invalidated breaking logout ### 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-2021-34428
GHSA-m6cp-vxjx-65j6 |