Headline
GHSA-6jwc-qr2q-7xwj: protocol-http1 HTTP Request/Response Smuggling vulnerability
Impact
RFC 9112 Section 7.1 defined the format of chunk size, chunk data and chunk extension (detailed ABNF is in Appendix section).
In summary:
- The value of Content-Length header should be a string of 0-9 digits.
- The chunk size should be a string of hex digits and should split from chunk data using CRLF.
- The chunk extension shouldn’t contain any invisible character.
However, we found that Falcon has following behaviors while disobey the corresponding RFCs.
- Falcon accepts Content-Length header values that have “+” prefix.
- Falcon accepts Content-Length header values that written in hexadecimal with “0x” prefix.
- Falcon accepts “0x” and “+” prefixed chunk size.
- Falcon accepts LF in chunk extension.
This behavior can lead to desync when forwarding through multiple HTTP parsers, potentially results in HTTP request smuggling and firewall bypassing. Note that while these issues were reproduced in Falcon (the server), the issue is with protocol-http1 which implements the HTTP/1 protocol parser. We have not yet been advised of any real world exploit or practical attack.
Patches
Fixed in protocol-http1 v0.15.1+.
Workarounds
No.
References
https://github.com/socketry/protocol-http1/pull/20
Impact
RFC 9112 Section 7.1 defined the format of chunk size, chunk data and chunk extension (detailed ABNF is in Appendix section).
In summary:
- The value of Content-Length header should be a string of 0-9 digits.
- The chunk size should be a string of hex digits and should split from chunk data using CRLF.
- The chunk extension shouldn’t contain any invisible character.
However, we found that Falcon has following behaviors while disobey the corresponding RFCs.
- Falcon accepts Content-Length header values that have “+” prefix.
- Falcon accepts Content-Length header values that written in hexadecimal with “0x” prefix.
- Falcon accepts “0x” and “+” prefixed chunk size.
- Falcon accepts LF in chunk extension.
This behavior can lead to desync when forwarding through multiple HTTP parsers, potentially results in HTTP request smuggling and firewall bypassing. Note that while these issues were reproduced in Falcon (the server), the issue is with protocol-http1 which implements the HTTP/1 protocol parser. We have not yet been advised of any real world exploit or practical attack.
Patches
Fixed in protocol-http1 v0.15.1+.
Workarounds
No.
References
socketry/protocol-http1#20
References
- GHSA-6jwc-qr2q-7xwj
- socketry/protocol-http1#20
- socketry/protocol-http1@e11fc16
Related news
protocol-http1 provides a low-level implementation of the HTTP/1 protocol. RFC 9112 Section 7.1 defined the format of chunk size, chunk data and chunk extension. The value of Content-Length header should be a string of 0-9 digits, the chunk size should be a string of hex digits and should split from chunk data using CRLF, and the chunk extension shouldn't contain any invisible character. However, Falcon has following behaviors while disobey the corresponding RFCs: accepting Content-Length header values that have `+` prefix, accepting Content-Length header values that written in hexadecimal with `0x` prefix, accepting `0x` and `+` prefixed chunk size, and accepting LF in chunk extension. This behavior can lead to desync when forwarding through multiple HTTP parsers, potentially results in HTTP request smuggling and firewall bypassing. This issue is fixed in `protocol-http1` v0.15.1. There are no known workarounds.