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 | |
parent | 9674f3e3a6b8e0e7183417aedac574ba7597c19f (diff) | |
download | waitress-38a1186cf42645384acd1027ca6c0d1e59a38911.tar.gz |
Move CHANGES to HISTORY
-rw-r--r-- | CHANGES.txt | 167 | ||||
-rw-r--r-- | HISTORY.txt | 167 |
2 files changed, 167 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 diff --git a/HISTORY.txt b/HISTORY.txt index b7ef0aa..1259aea 100644 --- a/HISTORY.txt +++ b/HISTORY.txt @@ -1,3 +1,170 @@ +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 + 1.3.1 (2019-08-27) ------------------ |