Impact
The original report:
A year ago we added Jetty’s GzipHandler to decompress requests with a certain URL path. We hit CVE-2020-27218 (GHSA-86wm-rrjm-8wh8) and upgrading to Jetty 9.4.53 fixed the issue. Over the past few months we upgraded Jetty several times and we are currently on 9.4.56.
Recently we received reports from a customer where they saw unexpected results from their API requests. Upon investigation we narrowed down the problem in the Jetty layer and the issue looks very similar to CVE-2020-27218 but slightly different.
The symptom: A portion of the request body from request A overwrites a portion of the request body from request B. The resulting content of request A seems to be intact with no modifications. The resulting content of request B is a mix of original content A and original content B. There is no exception from neither request A nor request B, and both requests are consumed fully. Both requests have an uncompressed request body.
To understand when this issue started, we looked at occurrences of this data leakage and the first occurrence of it was when we upgraded to Jetty 9.4.53 to fix CVE-2020-27218.
To fix the new issue, we implemented our own GzipHandler that extends from Jetty’s GzipHandler and found that if we bypass Jetty’s handler for such requests then the issue no longer occurs. We suspect that this portion (https://github.com/jetty/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/handler/gzip/GzipHandler.java#L630-L717) of the GzipHandler code unintentionally affects uncompressed requests in high volume environments.
Here is some additional information on the different types of requests handled by Jetty in our environment.
/path1: This path is set in the includedPaths for the GzipHandler. These are gzip’ed requests.
/path2: This path is not set in the includedPaths. Requests to this path can be either uncompressed or compressed. If compressed, servlet handles it based on the content encoding.
We have observed the issue only in uncompressed requests to /path2. (Both requests A and B described in the symptom are uncompressed.) The custom GzipHandler we implemented checks if the request is to /path2 and calls _handler.handle, essentially bypassing Jetty’s GzipHandler for all requests going to this path. For requests to /path1, it calls super.handle and defers to Jetty’s GzipHandler.
How to reproduce?
We have yet to find a way to reproduce. So far this issue is only observed in our production environment with a very high volume of requests.
Workarounds
The issue can be avoid by disabling (or not enabling) gzip inflation of request body content.
maimaisie Reporter
samjsong Other
nchudasmasumo Other
lei-sumo Other
Impact
The original report:
A year ago we added Jetty’s GzipHandler to decompress requests with a certain URL path. We hit CVE-2020-27218 (GHSA-86wm-rrjm-8wh8) and upgrading to Jetty 9.4.53 fixed the issue. Over the past few months we upgraded Jetty several times and we are currently on 9.4.56.
Recently we received reports from a customer where they saw unexpected results from their API requests. Upon investigation we narrowed down the problem in the Jetty layer and the issue looks very similar to CVE-2020-27218 but slightly different.
The symptom: A portion of the request body from request A overwrites a portion of the request body from request B. The resulting content of request A seems to be intact with no modifications. The resulting content of request B is a mix of original content A and original content B. There is no exception from neither request A nor request B, and both requests are consumed fully. Both requests have an uncompressed request body.
To understand when this issue started, we looked at occurrences of this data leakage and the first occurrence of it was when we upgraded to Jetty 9.4.53 to fix CVE-2020-27218.
To fix the new issue, we implemented our own GzipHandler that extends from Jetty’s GzipHandler and found that if we bypass Jetty’s handler for such requests then the issue no longer occurs. We suspect that this portion (https://github.com/jetty/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/handler/gzip/GzipHandler.java#L630-L717) of the GzipHandler code unintentionally affects uncompressed requests in high volume environments.
Here is some additional information on the different types of requests handled by Jetty in our environment.
We have observed the issue only in uncompressed requests to /path2. (Both requests A and B described in the symptom are uncompressed.) The custom GzipHandler we implemented checks if the request is to /path2 and calls _handler.handle, essentially bypassing Jetty’s GzipHandler for all requests going to this path. For requests to /path1, it calls super.handle and defers to Jetty’s GzipHandler.
How to reproduce?
We have yet to find a way to reproduce. So far this issue is only observed in our production environment with a very high volume of requests.
Workarounds
The issue can be avoid by disabling (or not enabling) gzip inflation of request body content.