CVE-2019-16785 – waitress

Package

Manager: pip
Name: waitress
Vulnerable Version: >=0 <1.4.0

Severity

Level: Medium

CVSS v3.1: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N

CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N

EPSS: 0.00433 pctl0.6187

Details

HTTP Request Smuggling: LF vs CRLF handling in Waitress ### Impact Waitress implemented a &quot;MAY&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&#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&#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: pylons-project-security@googlegroups.com (if security related)

Metadata

Created: 2019-12-20T23:03:57Z
Modified: 2024-11-19T13:55:58Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2019/12/GHSA-pg36-wpm5-g57p/GHSA-pg36-wpm5-g57p.json
CWE IDs: ["CWE-444"]
Alternative ID: GHSA-pg36-wpm5-g57p
Finding: F110
Auto approve: 1