CVE-2021-28165

In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.

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:

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:

  <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

From the reporter

XmlParser is vulnerable to XML external entity (XXE) vulnerability. XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit this vulnerability in order to achieve SSRF or cause a denial of service. One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the WAR includes a malicious web.xml.

Impact

There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit XmlParser the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation.

Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory.

However, any direct usage of the XmlParser class by an application may be vulnerable. The impact would greatly depend on how the application uses XmlParser, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely.

Patches

Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067

Workarounds

Don't use Jetty's XmlParser to parse data from users.

%global desc \ Jetty is a 100% Java HTTP Server and Servlet Container. This means that you\ do not need to configure and run a separate web server (like Apache) in order\ to use Java, servlets and JSPs to generate dynamic content. Jetty is a fully\ featured web server for static and dynamic content. Unlike separate\ server/container solutions, this means that your web server and web\ application run in the same process, without interconnection overheads\ and complications. Furthermore, as a pure java component, Jetty can be simply\ included in your application for demonstration, distribution or deployment.\ Jetty is available on all Java supported platforms. %{desc} %global extdesc %{desc}\ \ This package contains

Security Fix(es):

In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values.(CVE-2020-27223)

In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.(CVE-2021-28165)

In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.

In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.

TuxCare rebuilt 2 org.eclipse.jetty packages to address 6 CVEs. Fixed in 7.6.0.v20120127-tuxcare.1.

TuxCare rebuilt 2 packages to address 5 CVEs. Fixed in 9.4.24.v20191120-tuxcare.2.

TuxCare rebuilt 4 org.eclipse.jetty packages to address 12 CVEs. Fixed in 9.2.16.v20160414-tuxcare.1.

This update for jetty-minimal fixes the following issues:

Update to version 9.4.42.v20210604

• Fix: bsc#1187117, CVE-2021-28169 - possible for requests to the ConcatServlet with a doubly encoded path to access protected resources within the WEB-INF directory
• Fix: bsc#1184367, CVE-2021-28165 - jetty server high CPU when client send data length > 17408
• Fix: bsc#1184368, CVE-2021-28164 - Normalize ambiguous URIs
• Fix: bsc#1184366, CVE-2021-28163 - Exclude webapps directory from deployment scan

These are all security issues fixed in the jetty-annotations-9.4.43-1.2 package on the GA media of openSUSE Tumbleweed.

This update for jetty-minimal fixes the following issues:

Update to version 9.4.42.v20210604

• Fix: bsc#1187117, CVE-2021-28169 - possible for requests to the ConcatServlet with a doubly encoded path to access protected resources within the WEB-INF directory
• Fix: bsc#1184367, CVE-2021-28165 - jetty server high CPU when client send data length > 17408
• Fix: bsc#1184368, CVE-2021-28164 - Normalize ambiguous URIs
• Fix: bsc#1184366, CVE-2021-28163 - Exclude webapps directory from deployment scan