Search for packages
| purl | pkg:maven/org.eclipse.jetty/jetty-util@9.4.38.v20210224 |
| Next non-vulnerable version | 9.4.39.v20210325 |
| Latest non-vulnerable version | 12.0.1 |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-kxtv-ma18-8fer
Aliases: CVE-2021-28163 GHSA-j6qj-j888-vvgq |
Directory exposure in jetty ### Impact If the `${jetty.base}` directory or the `${jetty.base}/webapps` directory is a symlink (soft link in Linux), the contents of the `${jetty.base}/webapps` directory may be deployed as a static web application, exposing the content of the directory for download. For example, the problem manifests in the following `${jetty.base}`: ```$ tree demo-base/ demo-base/ ├── etc ├── lib ├── resources ├── start.d ├── deploy │ └── async-rest.war └── webapps -> deploy ``` ### Workarounds Do not use a symlink |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-prd3-mmuv-n3dc
Aliases: CVE-2021-28165 GHSA-26vr-8j45-3r4w |
Jetty vulnerable to incorrect handling of invalid large TLS frame, exhausting CPU resources ### Impact When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage. ### Workarounds The problem can be worked around by compiling the following class: ```java package org.eclipse.jetty.server.ssl.fix6072; import java.nio.ByteBuffer; import javax.net.ssl.SSLEngine; import javax.net.ssl.SSLEngineResult; import javax.net.ssl.SSLException; import javax.net.ssl.SSLHandshakeException; import org.eclipse.jetty.io.EndPoint; import org.eclipse.jetty.io.ssl.SslConnection; import org.eclipse.jetty.server.Connector; import org.eclipse.jetty.server.SslConnectionFactory; import org.eclipse.jetty.util.BufferUtil; import org.eclipse.jetty.util.annotation.Name; import org.eclipse.jetty.util.ssl.SslContextFactory; public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory { public SpaceCheckingSslConnectionFactory(@Name("sslContextFactory") SslContextFactory factory, @Name("next") String nextProtocol) { super(factory, nextProtocol); } @Override protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine) { return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption()) { @Override protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException { SSLEngineResult results = super.unwrap(sslEngine, input, output); if ((results.getStatus() == SSLEngineResult.Status.BUFFER_UNDERFLOW || results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) && BufferUtil.space(input) == 0) { BufferUtil.clear(input); throw new SSLHandshakeException("Encrypted buffer max length exceeded"); } return results; } }; } } ``` This class can be deployed by: + The resulting class file should be put into a jar file (eg sslfix6072.jar) + The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib + Copy the file `${jetty.home}/modules/ssl.mod` to `${jetty.base}/modules` + Edit the `${jetty.base}/modules/ssl.mod` file to have the following section: ``` [lib] lib/sslfix6072.jar ``` + Copy the file `${jetty.home}/etc/jetty-https.xml` and`${jetty.home}/etc/jetty-http2.xml` to `${jetty.base}/etc` + Edit files `${jetty.base}/etc/jetty-https.xml` and `${jetty.base}/etc/jetty-http2.xml`, changing any reference of `org.eclipse.jetty.server.SslConnectionFactory` to `org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory`. For example: ```xml <Call name="addIfAbsentConnectionFactory"> <Arg> <New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory"> <Arg name="next">http/1.1</Arg> <Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg> </New> </Arg> </Call> ``` + Restart Jetty |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-p7cu-h519-83hx | Authorization Before Parsing and Canonicalization in jetty Release 9.4.37 introduced a more precise implementation of [RFC3986](https://tools.ietf.org/html/rfc3986#section-3.3) with regards to URI decoding, together with some new compliance modes to optionally allow support of some URI that may have ambiguous interpretation within the Servlet specified API methods behaviours. The default mode allowed % encoded . characters to be excluded for URI normalisation, which is correct by the RFC, but is not assumed by common Servlet implementations. The default compliance mode allows requests with URIs that contain `%2e` or `%2e%2e` segments to access protected resources within the `WEB-INF` directory. For example a request to `/context/%2e/WEB-INF/web.xml` can retrieve the `web.xml` file. This can reveal sensitive information regarding the implementation of a web application. Workarounds found by HttpCompliance mode RFC7230_NO_AMBIGUOUS_URIS can be enabled by updating `start.d/http.ini` to include: jetty.http.compliance=RFC7230_NO_AMBIGUOUS_URIS. |
CVE-2021-28164
GHSA-v7ff-8wcx-gmc5 |