~ / search / GHSA-pg36-wpm5-g57p

GHSA-pg36-wpm5-g57p

HTTP Request Smuggling: LF vs CRLF handling in Waitress

Source: GitHub Advisory Database (reviewed) Moderate CVE-2019-16785

Packages

EcosystemPackageAffectedFixed in
PyPI waitress < 1.4.0 1.4.0

Details

As written in the advisory (Markdown source, shown as plain text).

### Impact Waitress implemented a &amp;quot;MAY&amp;quot; part of the RFC7230 (https://tools.ietf.org/html/rfc7230#section-3.5) which states: Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. Unfortunately if a front-end server does not parse header fields with an LF the same way as it does those with a CRLF it can lead to the front-end and the back-end server parsing the same HTTP message in two different ways. This can lead to a potential for HTTP request smuggling/splitting whereby Waitress may see two requests while the front-end server only sees a single HTTP message. Example: ``` Content-Length: 100[CRLF] X-Header: x[LF]Content-Length: 0[CRLF] ``` Would get treated by Waitress as if it were: ``` Content-Length: 100 X-Header: x Content-Length: 0 ``` This could potentially get used by attackers to split the HTTP request and smuggle a second request in the body of the first. ### Patches This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies. Waitress no longer implements the MAY part of the specification and instead requires that all lines are terminated correctly with CRLF. If any lines are found with a bare CR or LF a 400 Bad Request is sent back to the requesting entity. The Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don&amp;#39;t cause any changes in behavior. ### Workarounds Various reverse proxies may have protections against sending potentially bad HTTP requests to the backend, and or hardening against potential issues like this. If the reverse proxy doesn&amp;#39;t use HTTP/1.1 for connecting to the backend issues are also somewhat mitigated, as HTTP pipelining does not exist in HTTP/1.0 and Waitress will close the connection after every single request (unless the Keep Alive header is explicitly sent... so this is not a fool proof security method) ### Issues/more security issues: * open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related) * email the Pylons Security mailing list: [email protected] (if security related)

References

External links from the advisory. They lead to third-party sites.