Package Instance

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.

The Eclipse Jetty Server Artifact has a Gzip request memory leak
### Description (as reported)

There is a memory leak when using `GzipHandler` in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I'm reporting this as a vulnerability.

The leak is created by requests where the request is inflated (`Content-Encoding: gzip`) and the response is not deflated (no `Accept-Encoding: gzip`). In these conditions, a new inflator will be created by `GzipRequest` and never released back into `GzipRequest.__inflaterPool` because `gzipRequest.destory()` is not called.

In heap dumps one can see thousands of `java.util.zip.Inflator` objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs.

Code path in `GzipHandler.handle()`:
1. Line 601: `GzipRequest` is created when request inflation is needed.
2. Lines 611-616: The callback is only wrapped in `GzipResponseAndCallback` when both inflation and deflation are needed.
3. Lines 619-625: If the handler accepts the request (returns true), `gzipRequest.destroy()` is only called in the "request not accepted" path (returns false)

When deflation is needed, `GzipResponseAndCallback` (lines 102 and 116) properly calls `gzipRequest.destroy()` in its `succeeded()` and `failed()` methods. But this wrapper is only created when deflation is needed.

Possible fix:
The callback should be wrapped whenever a `GzipRequest` is created, not just when deflation is needed. This ensures `gzipRequest.destroy()` is always called when the request completes.


### Impact
The leak causes the JVM to crash with OOME.

### Patches
No patches yet.

### Workarounds
Disable `GzipHandler`.

### References
https://github.com/jetty/jetty.project/issues/14260

https://gitlab.eclipse.org/security/cve-assignment/-/issues/79

Eclipse Jetty's ThreadLimitHandler.getRemote() vulnerable to remote DoS attacks
### 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

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.