-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
https://gitlab.cee.redhat.com/undertow-io/undertow/-/merge_requests/126, https://gitlab.cee.redhat.com/undertow-io/undertow/-/commit/15ebd5d2f6539a2923a25fbf60ca74039b20c68a, https://github.com/undertow-io/undertow/pull/1715, https://github.com/undertow-io/undertow/pull/1753, https://github.com/undertow-io/undertow/pull/1754
Undertow might incorrectly re-use an HTTP request header value from a previous stream for a request associated with a subsequent stream on the same HTTP/2 connection. The issue is linked to the readHpackString method and its interaction with the stringBuilder field. While such behavior typically results in an error followed by the termination of the HTTP/2 connection, it presents a potential vector for information leakage between requests.
There is a similar issue in Apache Tomcat (CVE-2020-17527). In the patch for that vulnerability (https://github.com/apache/tomcat/commit/8d2fe6894d6e258a6d615d7f786acca80e6020cb) a StringBuilder field was improperly reused across multiple requests, leading to this issue. In the io.undertow.protocols.http2.HpackDecoder class of Undertow, within the readHpackString method, there is a code pattern identical to the one mentioned:
```
for (int i = 0; i < length; ++i)
String ret = stringBuilder.toString();
stringBuilder.setLength(0);
if (ret.isEmpty())
```