Explicit HTTP/2 requests smuggling handling

[krizhanovsky]

Requests smuggling

References

• https://portswigger.net/research/http2
• https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
• https://www.intruder.io/research/practical-http-header-smuggling
• https://www.youtube.com/watch?v=Zm-myHU8-RQ

I used Burp Community Edition to test the issue, Repeater tool.

Tempesta FW as of b655e31 doesn't allow a request like (data length is 16)

POST / HTTP/2
Host: tempesta-tech.com
Content-Length: 4

abcdGET /n HTT

, but the debug log is quite obscure for body parsing

[25946.330416] [tempesta fw]     Received 16 client data bytes on conn=00000000c791fef3 msg=000000001f11bbae
[25946.333088] [tempesta fw]       tfw_h2_parse_body: init, content_length=4, to_read=16
[25946.334126] [tempesta fw]       tfw_h2_parse_body: to_read=0, m_len=16, len=16
[25946.336282] [tempesta fw]       store field chunk len=16 data=        pK-error(a) field=<        pK-error,0x0,0,        pK-error>
[25946.338409] [tempesta fw]     Request parsed: len=16 next=        pK-error parsed=16 msg_len=36 ver=4 res=-4094
[25946.343270] [tempesta fw]   frang: check request for client 192.168.100.1, acc=00000000a4eb5fc1
[25946.344067] [tempesta fw]   frang: check incomplete request body for client 192.168.100.1, acc=00000000a4eb5fc1
[25946.345582] [tempesta fw]       enter frang FSM at state 0x6(Frang_Req_Body)
[25946.347391] [tempesta fw]       Finish frang FSM at state 0x6, ret=0
[25946.348741] [tempesta fw]       TFW_HTTP_FSM_REQ_CHUNK return code 0

tfw_h2_parse_body() function does print Content-Length for debugging, but does not validate it against the actual DATA length. I played with varying the data length, but didn't succeed on request smuggling.

@RomanBelozerov it'd be good to research this more with the issue assignee and implement an actual test exploiting the problem, if we actually have it.

Tempesta must explicitly validate Content-Length and return 400 as for other request smuggling attacks.

Reporting for the bad requests

Another issue is that with the request above we have 'phantom' requests in the perfstat:

Client messages received		: 9
Client messages forwarded		: 0
Client messages served from cache	: 0
Client messages parsing errors		: 0
Client messages filtered out		: 0
Client messages other errors		: 0

9 requests were received, but they were not dropped, not forwarded and not serviced from the cache? There is 0 client connections, so they also not in queue. Need to fix the statistic or introduce a new metric, which can account the requests.

Testing

The authors of the articles from the reference list actually mangled headers, such as Content-Length, X-Forwarded-For and so on, and observed the tested setup behavior. Our fuzzer must be extended to do the mutations as considered in the articles. Different headers should be mangled in the proposed ways. Maybe a new testing issue is required for this.

[krizhanovsky]

It seems this is a Burp issue. I retried the request with curl:

curl -i -v -k --http2 -H 'Content-Length: 9' -X POST --data 'abcd=dgdfGET /n HTTP/1.1\r\nHost: 02.rs?x.netflix.com\r\nFoo: bar' https://tempesta-tech.com

and I got

HTTP/2 400 
date: Sat, 18 May 2024 21:56:15 GMT
content-length: 0
server: Tempesta FW/0.8.0

with Warning: Request parsing inconsistency: 192.168.100.1 in log.

[krizhanovsky]

OK, it seems we're good and do not pass any of the attack samples (I was playing with Burp and curl for the whole evening), but it's still worth checking our test suite for the attack samples and implement them in case of further regressions.

I'd be cool if you could break our protection against request smuggling attack.

Also please investigate the issue with Burp: maybe it was just a misuse on my side or the tool or Tempesta have some framing (I suppose) bug. If so then, the bug should be revealed and reported.

[krizhanovsky]

On this screenshot Burp hangs in waiting for a response. Maybe there is a problem with the showing HTTP/2 as HTTP/1 feature...

[const-t]

tfw_h2_parse_body() function does print Content-Length for debugging, but does not validate it against the actual DATA length. I played with varying the data length, but didn't succeed on request smuggling.

Looks like END_STREAM was not received. When END_STREAM is received tfw_h2_parse_req_finish() validates Content-Length against actual body length(total size of DATA frames), while END_STREAM not received Tempesta just waits next frame.