Encoded URIs can access WEB-INF directory in Eclipse Jetty

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.