diff options
author | Bert JW Regeer <bertjw@regeer.org> | 2020-11-26 22:38:17 -0800 |
---|---|---|
committer | Bert JW Regeer <bertjw@regeer.org> | 2020-11-26 22:38:17 -0800 |
commit | 38a1186cf42645384acd1027ca6c0d1e59a38911 (patch) | |
tree | c8af7a9a8be963bc755b1bf94d2c81cd571bae15 /CHANGES.txt | |
parent | 9674f3e3a6b8e0e7183417aedac574ba7597c19f (diff) | |
download | waitress-38a1186cf42645384acd1027ca6c0d1e59a38911.tar.gz |
Move CHANGES to HISTORY
Diffstat (limited to 'CHANGES.txt')
-rw-r--r-- | CHANGES.txt | 167 |
1 files changed, 0 insertions, 167 deletions
diff --git a/CHANGES.txt b/CHANGES.txt index 6e28bdd..467de26 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -31,170 +31,3 @@ accepting new connections. This situation was previously difficult to diagnose. See https://github.com/Pylons/waitress/pull/322 - -1.4.4 (2020-06-01) ------------------- - -- Fix an issue with keep-alive connections in which memory usage was higher - than expected because output buffers were being reused across requests on - a long-lived connection and each buffer would not be freed until it was full - or the connection was closed. Buffers are now rotated per-request to - stabilize their behavior. - - See https://github.com/Pylons/waitress/pull/300 - -- Waitress threads have been updated to contain their thread number. This will - allow loggers that use that information to print the thread that the log is - coming from. - - See https://github.com/Pylons/waitress/pull/302 - -1.4.3 (2020-02-02) ------------------- - -Security Fixes -~~~~~~~~~~~~~~ - -- In Waitress version 1.4.2 a new regular expression was added to validate the - headers that Waitress receives to make sure that it matches RFC7230. - Unfortunately the regular expression was written in a way that with invalid - input it leads to catastrophic backtracking which allows for a Denial of - Service and CPU usage going to a 100%. - - This was reported by Fil Zembowicz to the Pylons Project. Please see - https://github.com/Pylons/waitress/security/advisories/GHSA-73m2-3pwg-5fgc - for more information. - -1.4.2 (2020-01-02) ------------------- - -Security Fixes -~~~~~~~~~~~~~~ - -- This is a follow-up to the fix introduced in 1.4.1 to tighten up the way - Waitress strips whitespace from header values. This makes sure Waitress won't - accidentally treat non-printable characters as whitespace and lead to a - potental HTTP request smuggling/splitting security issue. - - Thanks to ZeddYu Lu for the extra test cases. - - Please see the security advisory for more information: - https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 - - CVE-ID: CVE-2019-16789 - -Bugfixes -~~~~~~~~ - -- Updated the regex used to validate header-field content to match the errata - that was published for RFC7230. - - See: https://www.rfc-editor.org/errata_search.php?rfc=7230&eid=4189 - - -1.4.1 (2019-12-24) ------------------- - -Security Fixes -~~~~~~~~~~~~~~ - -- Waitress did not properly validate that the HTTP headers it received were - properly formed, thereby potentially allowing a front-end server to treat a - request different from Waitress. This could lead to HTTP request - smuggling/splitting. - - Please see the security advisory for more information: - https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 - - CVE-ID: CVE-2019-16789 - -1.4.0 (2019-12-20) ------------------- - -Bugfixes -~~~~~~~~ - -- Waitress used to slam the door shut on HTTP pipelined requests without - setting the ``Connection: close`` header as appropriate in the response. This - is of course not very friendly. Waitress now explicitly sets the header when - responding with an internally generated error such as 400 Bad Request or 500 - Internal Server Error to notify the remote client that it will be closing the - connection after the response is sent. - -- Waitress no longer allows any spaces to exist between the header field-name - and the colon. While waitress did not strip the space and thereby was not - vulnerable to any potential header field-name confusion, it should have sent - back a 400 Bad Request. See https://github.com/Pylons/waitress/issues/273 - -Security Fixes -~~~~~~~~~~~~~~ - -- Waitress implemented a "MAY" 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. - - For more information I can highly recommend the blog post by ZeddYu Lu - https://blog.zeddyu.info/2019/12/08/HTTP-Smuggling-en/ - - Please see the security advisory for more information: - https://github.com/Pylons/waitress/security/advisories/GHSA-pg36-wpm5-g57p - - CVE-ID: CVE-2019-16785 - -- Waitress used to treat LF the same as CRLF in ``Transfer-Encoding: chunked`` - requests, while the maintainer doesn't believe this could lead to a security - issue, this is no longer supported and all chunks are now validated to be - properly framed with CRLF as required by RFC7230. - -- Waitress now validates that the ``Transfer-Encoding`` header contains only - transfer codes that it is able to decode. At the moment that includes the - only valid header value being ``chunked``. - - That means that if the following header is sent: - - ``Transfer-Encoding: gzip, chunked`` - - Waitress will send back a 501 Not Implemented with an error message stating - as such, as while Waitress supports ``chunked`` encoding it does not support - ``gzip`` and it is unable to pass that to the underlying WSGI environment - correctly. - - Waitress DOES NOT implement support for ``Transfer-Encoding: identity`` - eventhough ``identity`` was valid in RFC2616, it was removed in RFC7230. - Please update your clients to remove the ``Transfer-Encoding`` header if the - only transfer coding is ``identity`` or update your client to use - ``Transfer-Encoding: chunked`` instead of ``Transfer-Encoding: identity, - chunked``. - - Please see the security advisory for more information: - https://github.com/Pylons/waitress/security/advisories/GHSA-g2xc-35jw-c63p - - CVE-ID: CVE-2019-16786 - -- While validating the ``Transfer-Encoding`` header, Waitress now properly - handles line-folded ``Transfer-Encoding`` headers or those that contain - multiple comma seperated values. This closes a potential issue where a - front-end server may treat the request as being a chunked request (and thus - ignoring the Content-Length) and Waitress using the Content-Length as it was - looking for the single value ``chunked`` and did not support comma seperated - values. - -- Waitress used to explicitly set the Content-Length header to 0 if it was - unable to parse it as an integer (for example if the Content-Length header - was sent twice (and thus folded together), or was invalid) thereby allowing - for a potential request to be split and treated as two requests by HTTP - pipelining support in Waitress. If Waitress is now unable to parse the - Content-Length header, a 400 Bad Request is sent back to the client. - - Please see the security advisory for more information: - https://github.com/Pylons/waitress/security/advisories/GHSA-4ppp-gpcr-7qf6 |