Skip to content

Encoded URIs can access WEB-INF directory in Eclipse Jetty

Moderate severity GitHub Reviewed Published Jul 15, 2021 in jetty/jetty.project • Updated Jan 27, 2023

Package

maven org.eclipse.jetty:jetty-webapp (Maven)

Affected versions

>= 9.4.37, < 9.4.43
>= 10.0.1, < 10.0.6
>= 11.0.1, < 11.0.6

Patched versions

9.4.43
10.0.6
11.0.6

Description

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.

References

Published by the National Vulnerability Database Jul 15, 2021
@waynebeaton waynebeaton published to jetty/jetty.project Jul 15, 2021
Reviewed Jul 15, 2021
Published to the GitHub Advisory Database Jul 19, 2021
Last updated Jan 27, 2023

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

EPSS score

60.129%
(98th percentile)

Weaknesses

CVE ID

CVE-2021-34429

GHSA ID

GHSA-vjv5-gp2w-65vm

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.