CVE-2021-34429 — jetty-webapp

Description

URIs can be crafted using some encoded characters to access the content of the WEB-INF directory and/or bypass some security constraints. This is a variation of the vulnerability reported in CVE-2021-28164/GHSA-v7ff-8wcx-gmc5.

Impact

The default compliance mode allows requests with URIs that contain a %u002e segment to access protected resources within the WEB-INF directory. For example, a request to /%u002e/WEB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application. Similarly, an encoded null character can prevent correct normalization so that /.%00/WEB-INF/web.xml cal also retrieve the web.xml file.

Workarounds

Some Jetty rewrite rules can be deployed to rewrite any request containing encoded dot segments or null characters in the raw request URI, to a known not found resource:

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewriteRegexRule">
      <Set name="regex">.*/(?:\.+/)+.*</Set>
      <Set name="replacement">/WEB-INF/Not-Found</Set>
    </New>
  </Arg>
</Call>
<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.ValidUrlRule"/>
  </Arg>
</Call>

Analysis

Prior to 9.4.37, Jetty was protected from this style of attack by two lines of defense:

• URIs were decoded first and then normalized for . and .. sequences. Whilst this is not according to the RFC, it did remove relative segments that were encoded or parameterized and made the resulting URI paths safe from any repeated normalization (often done by URI manipulation and file system mapping).
• The FileResource class treated any difference between absolute path and canonical path of a resource as an alias, and thus the resource would not be served by default.

Prior to 9.4.37, the FileResource class was replaced by the PathResource class that did not treat normalization differences as aliases. Then release 9.4.37 updated the URI parsing to be compliant with the RFC, in that normalization is done before decoding. This allowed various encodings or adornments to relative path segments that would not be normalized by the pure RFC URI normalization, but were normalized by the file system, thus allowing protected resources to be accessed via an alias. Specifically by decoding URIs after normalization, it left them vulnerable to any subsequent normalization (potentially after checking security constraints) changing the URI singificantly. Such extra normalization is often down by URI manipulation code and file systems.

With Jetty releases 9.4.43, 10.0.6, 11.0.6, we have restored several lines of defense:

• URIs are first decoded and then normalized which is not strictly according to the current RFC. Since the normalization is done after decoding, the URI paths produced are safe from further normalisation and the referenced resource cannot easily be so changed after passing security constraints.
• During URI parsing checks are made for some specific segments/characters that are possible to be seen ambiguously by an application (e.g. encode dot segments, encoded separators, empty segments, parameterized dot segments and/or null characters). So even though Jetty code handles these URIs correctly, there is a risk that an application may not do so, thus such requests are rejected with a 400 Bad Request unless a specific compliance mode is set.
• Once decoded and normalized by initial URI processing, Jetty will not decode or normalize a received URI again within its own resource handling. This avoids to possibility of double decode attacks.
• The ContextHandler.getResource(String path) method always checks that the passed path is normalized, only accepting a non normal path if approved by an AliasChecker. This is the method that is directly used by Jetty resource serving.
• The API methods like ServletContext.getResource(String path) will normalize the prior to calling ContextHandler.getResource(String path). This allows applications to use non normal paths.
• The PathResource class now considers any difference in normal/canonical name between a request resource name and the found resource name to be an alias, which will only be served if approved by an explicit AliasChecker

In summary, the defense is a front line of detection of specific known URI alias attacks, with the last line defense of not allowing any aliasing of resources.

Many thanks to @cangqingzhe from @CloverSecLabs for reporting this issue.