GHSA-8mpp-f3f7-xc28 CVE-2022-2191
Jetty SslConnection does not release pooled ByteBuffers in case of errors
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 2.18%
- Chance of exploitation in the next 30 days. Higher than 82.35% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-404 Improper Resource Shutdown or Release
- Fix
10.0.10- Upgrade org.eclipse.jetty:jetty-server to this version or later
Description
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
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| org.eclipse.jetty:jetty-server | >= 10.0.0, < 10.0.10 |
10.0.10 |
| org.eclipse.jetty:jetty-server | >= 11.0.0, < 11.0.10 |
11.0.10 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
org.eclipse.jetty:jetty-server Maven → 10.0.10
- maven
<dependency><groupId>org.eclipse.jetty</groupId><artifactId>jetty-server</artifactId><version>10.0.10</version></dependency>- gradle
implementation("org.eclipse.jetty:jetty-server:10.0.10")
Severity breakdown
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-404: Improper Resource Shutdown or Release
The product does not release or incorrectly releases a resource before it is made available for re-use.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Implementation: It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free memory in a function. If you allocate memory that you intend to free upon completion of the function, you must be sure to free the memory at all exit points for that function including error conditions.
- Implementation: Memory should be allocated/freed using matching functions such as malloc/free, new/delete, and new[]/delete[].
- Implementation: When releasing a complex object or structure, ensure that you properly dispose of all of its member components, not just the object itself.
References
Advisories
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-7p3p-8qv8-m2vh Eclipse Jetty: HTTP Authority/Host mismatch | Medium | Also affects org.eclipse.jetty:jetty-server |
| GHSA-f4v5-65jj-pcr2 Eclipse Jetty: Cross-Request Leakage for trailers on HTTP/1.1 keep-alive connections | High | Also affects org.eclipse.jetty:jetty-server |
| GHSA-9299-c6m4-mjhc Eclipse Jetty: DoS attack triggering OutOfMemory with 100-Continue requests | High | Also affects org.eclipse.jetty:jetty-server |
| GHSA-xxh7-fcf3-rj7f The Eclipse Jetty Server Artifact has a Gzip request memory leak | High | Also affects org.eclipse.jetty:jetty-server |
| GHSA-q4rv-gq96-w7c5 **UNSUPPORTED WHEN ASSIGNED** GzipHandler causes part of request body to be seen as request body of a separate request | High | Also affects org.eclipse.jetty:jetty-server |
| GHSA-g8m5-722r-8whq Eclipse Jetty's ThreadLimitHandler.getRemote() vulnerable to remote DoS attacks | Medium | Also affects org.eclipse.jetty:jetty-server |
| GHSA-p26g-97m4-6q7c Eclipse Jetty's cookie parsing of quoted values can exfiltrate values from other cookies | Medium | Also affects org.eclipse.jetty:jetty-server |
| GHSA-qw69-rqj8-6qw8 OutOfMemoryError for large multipart without filename in Eclipse Jetty | Medium | Also affects org.eclipse.jetty:jetty-server |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor