HTTP/2 trailer out-of-bounds read
libcurl contains an out bounds read in code handling HTTP/2 trailers. It was [reported](https://github.com/curl/curl/pull/2231) that reading an HTTP/2 trailer could mess up future trailers since the stored size was one byte less than required. The problem is that the code that creates HTTP/1-like headers from the HTTP/2 trailer data once appended a string like `":"` to the target buffer, while this was recently changed to `": "` (a space was added after the colon) but the associated math was not updated correspondingly. When accessed, the data is read out of bounds and causes either a crash or that the (too large) data gets passed to the libcurl callback. This might lead to a denial-of-service situation or an information disclosure if someone has a service that echoes back or uses the trailers for something.
02 / AFFECTED SOFTWARE
Affected packages
18 explicit affected versions
36 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
libcurl 7.49.0 to and including 7.57.0 contains an out bounds read in code handling HTTP/2 trailers. It was reported (https://github.com/curl/curl/pull/2231) that reading an HTTP/2 trailer could mess up future trailers since the stored size was one byte less than required. The problem is that the code that creates HTTP/1-like headers from the HTTP/2 trailer data once appended a string like `:` to the target buffer, while this was recently changed to `: ` (a space was added after the colon) but the following math wasn't updated correspondingly. When accessed, the data is read out of bounds and causes either a crash or that the (too large) data gets passed to client write. This could lead to a denial-of-service situation or an information disclosure if someone has a service that echoes back or uses the trailers for something.
libcurl contains an out bounds read in code handling HTTP/2 trailers. It was [reported](https://github.com/curl/curl/pull/2231) that reading an HTTP/2 trailer could mess up future trailers since the stored size was one byte less than required. The problem is that the code that creates HTTP/1-like headers from the HTTP/2 trailer data once appended a string like `":"` to the target buffer, while this was recently changed to `": "` (a space was added after the colon) but the associated math was not updated correspondingly. When accessed, the data is read out of bounds and causes either a crash or that the (too large) data gets passed to the libcurl callback. This might lead to a denial-of-service situation or an information disclosure if someone has a service that echoes back or uses the trailers for something.
05 / REFERENCES