Handling of content-length/transfer-encoding allows request smuggling

[ndrewh]

Send a request with the following headers:

transfer-encoding: chunked\t\r\n
content-length: 60\r\n

The check for chunked will fail because of the extra tab (\t), so Sozu will look at content-length when forwarding this request. However, Sozu also forwards the malformed transfer-encoding: chunked\t\r\n header. Depending on the backend that we are forwarding to, the backend may choose to use either the transfer-encoding or content-length header (e.g. gunicorn will trim the \t and consider this to be chunked). Sozu should not forward malformed transfer-encoding headers.

There is more info on request smuggling here. I don't think this is currently a huge deal for Sozu, since there aren't any authentication features in Sozu that you'd be bypassing. This was used as part of a CTF challenge, if anyone is curious to see in exactly what sort of scenario this vulnerability would be used.

[Geal]

That's an interesting bug, thanks. Also it's fun to see sozu used in a ctf 😅

I was wondering if that request smuggling can happen, well now we know. @FlorentinDUBOIS @Keksoj I think this is important enough to be fixed both in 0.13 and 0.14, WDYT?

[FlorentinDUBOIS]

Hello!

Thanks you to report this issue and the documentation. Yes, I think is enough important to backport the fix in the previous release. I will take a look at it :)

[FlorentinDUBOIS]

According to @Geal comments on the issue #739, the above need to be done without a copy which implies performance regression otherwise