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
http request smuggling, cause by obfuscating TE header #9571
Comments
|
Hi, it think the |
|
Also generally speaking I would upgrade to the latest netty version first and try to reproduce with it. The version you are using is very old. |
Actual source: https://tools.ietf.org/html/rfc7230#page-22):
It looks clear to me that your header name must be parsed as "Transfer-Encoding " with a trailing white space, so it's expected to not be handled as "Transfer-Encoding" by Netty (or any other solution that follows standards). IMHO, this is a bug in your client and you should get this fixed there. |
4.1.32.Final is in my project, and 4.1.41.final(https://github.com/netty/netty/blob/netty-4.1.41.Final/codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java) is the same like ch == ':' || Character.isWhitespace(ch)) |
some guy attack elb by both having TE[space] and CL. elb decode request by CL but netty decoded by TE[space]. this case some tail of the attack request inflect the next request(https://portswigger.net/web-security/request-smuggling). |
|
Ah OK!!! Sorry, I originally didn't get it. So I agree Netty's HttpObjectDecoder shouldn't trim header name. I don't know why it removes this whitespace, and I couldn't find way as things have been this way since the project has a git history. I'm in favor of removing this @normanmaurer WDYT? Have you even seen legit user agents crafting HTTP headers with a whitespace before the |
|
@slandelle nope... Can someone just do a PR with a unit test ? I currently super busy :( |
|
In order to fix the problem easily, I drew a topology of vulnerability principle below.
|
|
after a attemp, keep the space will colfict the validate rule in defaultHttpHeader(like header can not contain s=,;: ...), and the left body will also inflect the next request. by the way, we(me and @Bi3g0) are a team, can we record this on CVE |
|
It looks to me having a trailing white space in the header name is legit as per RFC7230, so IMHO, it shouldn't be renamed. |
|
yeah... @slandelle can you provide a pr ? |
Hi, I think we can reference rfc7230#section-3.2.4 https://tools.ietf.org/html/rfc7230#section-3.2.4
|
|
@Bi3g0 so what you think we should do ? I'm a bit confused atm :/ |
|
@normanmaurer 1)Netty can identify 2)Or Netty can identify We(@axeBig and me) just renamed |
|
@Bi3g0 I stand corrected, I wasn’t aware of this update :P. |
|
We have a property (DcoderResult?) that indicates whether the decoding was successful or not IIRC. How about using that, instead of automatically responding with 400? That way, a user could choose to 1) send a custom 400 response page, 2) just disconnect, or 3) do something interesting (like looking into the bad headers). |
|
@trustin |
|
I agree with @trustin ... I think we should just send a "InvalidMessage" down the pipeline... @slandelle WDYT ? |
|
Do you mean having a special MalformedHttpHeaderException passed through DecoderResult? |
|
Yep something like this
… Am 19.09.2019 um 13:44 schrieb Stephane Landelle ***@***.***>:
Do you mean having a special MalformedHttpHeaderException passed through DecoderResult?
If so, lgtm.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@slandelle can you take this one ? |
|
@normanmaurer Yes if you can wait a few days. |
…30#section-3.2.4 Motivation: When parsing HTTP headers special care needs to be taken when a whitespace is detected in the header name. Modifications: - Ignore whitespace when decoding response (just like before) - Throw exception when whitespace is detected during parsing - Add unit tests Result: Fixes #9571
|
@trustin @slandelle @axeBig @Bi3g0 please check #9585 |
|
So just to clarify... with the proposed PR all works as expected?
… Am 20.09.2019 um 15:36 schrieb Bi3g0 ***@***.***>:
We have tested it and the problem has been fixed.
When I sent an incorrect TE, netty returned 400 and disconnected the TCP connection.
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=utf-8
Content-Length: 147
Connection: close
decode request error,cause:java.lang.IllegalArgumentException: a header name cannot contain the following prohibited characters: =,;: \t\r\n\v\f:
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
when decode fail, we user decide what to do. looks fine to me. |
|
We just did a test and the problem has been fixed. When I sent an When users of netty do not deal with 400, other requests within TCP connections will not be responded to, or may consume additional network connections from servers. |
IMHO, Netty is a low level IO framework, not a web framework and it's the user's responsibility to deal with this situation. |
|
Okay, then there's no problem. |
…30#section-3.2.4 (#9585) Motivation: When parsing HTTP headers special care needs to be taken when a whitespace is detected in the header name. Modifications: - Ignore whitespace when decoding response (just like before) - Throw exception when whitespace is detected during parsing - Add unit tests Result: Fixes #9571
…30#section-3.2.4 (#9585) Motivation: When parsing HTTP headers special care needs to be taken when a whitespace is detected in the header name. Modifications: - Ignore whitespace when decoding response (just like before) - Throw exception when whitespace is detected during parsing - Add unit tests Result: Fixes #9571
|
CVE-2019-16869 was assigned to this issue. |
|
@abergmann: I am currently investigating this CVE for Debian LTS, I found another location in the code that looks pretty similar. Does it need that fix, too? |
|
Can someone explain why the CVE description says this affects versions before 4.1.42, but the CPE says it affects versions before 4.1.36??? |
fix netty bug #9571 netty/netty#9571
fix netty bug #9571 netty/netty#9571
|
Question, will / could there be fix for the 3.10.6 version coming out as well? |
|
No... 3.x is end of Life forever
… Am 09.11.2019 um 01:20 schrieb Moncef Ben-Soula ***@***.***>:
Question, will / could there be fix for the 3.10.6 version coming out as well?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
fix netty bug #9571 netty/netty#9571
|
Hi, I am using spring webflux 2.2.2.RELEASE with netty 4.1.43.Final, in an application that has 2 instances and is deployed in kubernetes and I have found this vulnerability when the TE is the first header and this header has a blank before the header name for example [space] Transfer-Encoding: chunked; reviewing the source code on the next line netty/codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java Line 766 in 8494b04
, blanks at the beginning of the header are excluded and for this reason the request continues and the vulnerability is subsequently presented; I ran this test on Akka Http and in this scenario he sends a 400 mentioning that the header name has an invalid name. Thank you |
|
@fabianedl777 can you please try to update to latest netty version (4.1.45.Final) and if you still be able to reproduce the issue send me a reproducer to my email (you can find it via GitHub). |
Compared against 4.1.25.6.dse, this tag cherry-picks upstream commits that fixed bugs in HttpObjectDecoder/HttpRequestDecoder, plus two intermediate refactoring commits that indirectly affect those bugfix commits. What follows is a list of PR links, issue links, CVE links, and hashes associated with the cherry-picked commits. Verify we do not receive multiple content-length headers or a content-length and transfer-encoding: chunked header when using HTTP/1.1 (netty#9865) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7238 netty#9861 netty#9865 8494b04 Detect missing colon when parsing http headers with no value (netty#9871) GHSA-cqqj-4p63-rrmm netty#9866 netty#9871 a7c18d4 Fix typos in javadocs (netty#9527) skipped Correctly handle whitespaces in HTTP header names as defined by RFC7230#section-3.2.4 (netty#9585) https://nvd.nist.gov/vuln/detail/CVE-2019-16869 netty#9571 netty#9585 39cafcb Use `AppendableCharSequence.charAtUnsafe(int)` in `HttpObjectDecoder` (netty#9492) netty#9492 85fcf4e use checkPositive/checkPositiveOrZero (netty#8835) netty#8835 4c64c98 HttpObjectDecoder ignores HTTP trailer header when empty line is rece… (netty#8799) netty#8736 netty#8799 91d3920
…30#section-3.2.4 (netty#9585) Motivation: When parsing HTTP headers special care needs to be taken when a whitespace is detected in the header name. Modifications: - Ignore whitespace when decoding response (just like before) - Throw exception when whitespace is detected during parsing - Add unit tests Result: Fixes netty#9571 (cherry picked from commit 39cafcb)
Compared against 4.1.34.2.dse, this tag cherry-picks upstream commits that fixed bugs in HttpObjectDecoder/HttpRequestDecoder, plus two intermediate refactoring commits that indirectly affect those bugfix commits. What follows is a list of PR links, issue links, CVE links, and hashes associated with the cherry-picked commits. Verify we do not receive multiple content-length headers or a content-length and transfer-encoding: chunked header when using HTTP/1.1 (netty#9865) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7238 netty#9861 netty#9865 8494b04 Detect missing colon when parsing http headers with no value (netty#9871) https://nvd.nist.gov/vuln/detail/CVE-2019-20444 netty#9866 netty#9871 a7c18d4 Fix typos in javadocs (netty#9527) skipped Correctly handle whitespaces in HTTP header names as defined by RFC7230#section-3.2.4 (netty#9585) https://nvd.nist.gov/vuln/detail/CVE-2019-16869 netty#9571 netty#9585 39cafcb Use `AppendableCharSequence.charAtUnsafe(int)` in `HttpObjectDecoder` (netty#9492) netty#9492 85fcf4e
Compared against 4.1.25.6.dse, this tag cherry-picks upstream commits that fixed bugs in HttpObjectDecoder/HttpRequestDecoder, plus two intermediate refactoring commits that indirectly affect those bugfix commits. What follows is a list of PR links, issue links, CVE links, and hashes associated with the cherry-picked commits. Verify we do not receive multiple content-length headers or a content-length and transfer-encoding: chunked header when using HTTP/1.1 (netty#9865) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7238 netty#9861 netty#9865 8494b04 Detect missing colon when parsing http headers with no value (netty#9871) GHSA-cqqj-4p63-rrmm netty#9866 netty#9871 a7c18d4 Fix typos in javadocs (netty#9527) skipped Correctly handle whitespaces in HTTP header names as defined by RFC7230#section-3.2.4 (netty#9585) https://nvd.nist.gov/vuln/detail/CVE-2019-16869 netty#9571 netty#9585 39cafcb Use `AppendableCharSequence.charAtUnsafe(int)` in `HttpObjectDecoder` (netty#9492) netty#9492 85fcf4e use checkPositive/checkPositiveOrZero (netty#8835) netty#8835 4c64c98 HttpObjectDecoder ignores HTTP trailer header when empty line is rece… (netty#8799) netty#8736 netty#8799 91d3920
Compared against 4.1.34.2.dse, this tag cherry-picks upstream commits that fixed bugs in HttpObjectDecoder/HttpRequestDecoder, plus two intermediate refactoring commits that indirectly affect those bugfix commits. What follows is a list of PR links, issue links, CVE links, and hashes associated with the cherry-picked commits. Verify we do not receive multiple content-length headers or a content-length and transfer-encoding: chunked header when using HTTP/1.1 (netty#9865) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7238 netty#9861 netty#9865 8494b04 Detect missing colon when parsing http headers with no value (netty#9871) https://nvd.nist.gov/vuln/detail/CVE-2019-20444 netty#9866 netty#9871 a7c18d4 Fix typos in javadocs (netty#9527) skipped Correctly handle whitespaces in HTTP header names as defined by RFC7230#section-3.2.4 (netty#9585) https://nvd.nist.gov/vuln/detail/CVE-2019-16869 netty#9571 netty#9585 39cafcb Use `AppendableCharSequence.charAtUnsafe(int)` in `HttpObjectDecoder` (netty#9492) netty#9492 85fcf4e



Expected behavior
ignore obfuscating TE header("Transfer-Encoding : chunked" vs "Transfer-Encoding: chunked")
Actual behavior
use Transfer-Encoding[space] as Transfer-Encoding
Steps to reproduce
1、topology: client→elb→nettyServer
2、client send a request with both content-length and trunked-encoded[space]
3、elb ignored trunked-encoded[space], but use content-length
4、netty use trunked-encoded[space]
Minimal yet complete reproducer code (or URL to code)
when header field end with space but not colon, shoud the space be ignored?
can not found proof in https://greenbytes.de/tech/webdav/rfc7230.html#header.fields.
code in io.netty.handler.codec.http.HttpObjectDecoder#splitHeader
for (nameEnd = nameStart; nameEnd < length; nameEnd ++) { char ch = sb.charAt(nameEnd); if (ch == ':' || Character.isWhitespace(ch)) { break; } }Netty version
all
JVM version (e.g.
java -version)OS version (e.g.
uname -a)The text was updated successfully, but these errors were encountered: