ATS accepts and forwards carriage returns within chunk-ext BWS

[kenballus]

RFCs 9110 and 9112 define the chunk-ext rule (and its dependencies) as follows:

chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
BWS = OWS
OWS = *( SP / HTAB )

Thus, a chunk-ext (which may follow a chunk size in a chunked HTTP message body) may begin with whitespace. The bug in ATS is that it accepts and forwards requests that contain carriage returns within that whitespace, even though only spaces and tabs should be permitted. To verify this for yourself, try sending the following request to an instance of ATS:

POST / HTTP/1.1\r\n
Transfer-Encoding: chunked\r\n
\r\n
1\r\r;chunk-ext-name\r\n
Z\r\n
0\r\n
\r\n

Note the invalid \r\r before the chunk extension name. ATS then forwards something this to the backend:

POST / HTTP/1.1\r\n
Client-ip: 172.18.0.1\r\n
X-Forwarded-For: 172.18.0.1\r\n
Via: http/1.1 traffic_server[90916a9b-0928-413b-8028-37facb5c2957] (ApacheTrafficServer/10.0.0)\r\n
Host: echo\r\n
Transfer-Encoding: chunked\r\n
\r\n
1\r\r;chunk-ext-name\r\n
Z\r\n
0\r\n
\r\n

Note that the invalid carriage returns made it through ATS.

This is of concern because there's a popular HTTP server that misinterprets carriage returns in this location.