Accepted waitress 1.2.0~b2-2+deb10u1 (source) into oldstable-proposed-updates->oldstable-new, oldstable-proposed-updates
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Wed, 11 May 2022 22:42:07 -0400
Source: waitress
Architecture: source
Version: 1.2.0~b2-2+deb10u1
Distribution: buster-security
Urgency: high
Maintainer: Andrej Shadura <andrewsh@debian.org>
Changed-By: Stefano Rivera <stefanor@debian.org>
Closes: 1008013
Changes:
waitress (1.2.0~b2-2+deb10u1) buster-security; urgency=high
.
* Non-maintainer upload by the Security Team.
* Security updates to fix request smuggling bugs, when combined with another
http proxy that interprets requests differently. 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.
This can result in cache poisoning or unexpected information disclosure.
The specific issues resolved are:
- CVE-2019-16785: Only recognise CRLF as a line-terminator, not a plain
LF. Before this change waitress could see two requests where the
front-end proxy only saw one.
- CVE-2019-16786: Waitress would parse the Transfer-Encoding header and
only look for a single string value, if that value was not "chunked" it
would fall through and use the Content-Length header instead.
This could allow for Waitress to treat a single request as multiple
requests in the case of HTTP pipelining.
- CVE-2019-16789: Specially crafted requests containing special whitespace
characters in the Transfer-Encoding header would get parsed by Waitress
as being a chunked request, but a front-end server would use the
Content-Length instead as the Transfer-Encoding header is considered
invalid due to containing invalid characters.
If a front-end server does HTTP pipelining to a backend Waitress server
this could lead to HTTP request splitting which may lead to potential
cache poisoning or unexpected information disclosure.
- CVE-2019-16792: If two Content-Length headers are sent in a single
request, Waitress would treat the request as having no body, thereby
treating the body of the request as a new request in HTTP pipelining.
- CVE-2022-24761: There are two classes of vulnerability that may lead to
request smuggling that are addressed by this advisory:
+ The use of Python's int() to parse strings into integers, leading to
+10 to be parsed as 10, or 0x01 to be parsed as 1, where as the
standard specifies that the string should contain only digits or hex
digits.
+ Waitress does not support chunk extensions, however it was discarding
them without validating that they did not contain illegal characters.
(Closes: #1008013)
Checksums-Sha1:
8dd87511156296e7408da902d6b31085a929da34 1643 waitress_1.2.0~b2-2+deb10u1.dsc
100e289d1b0048cd91c9ac4cf31667d59d8bbbb4 156556 waitress_1.2.0~b2.orig.tar.gz
3fd4378c31c8ecc5b41f2e477f4502f311c9a72d 22276 waitress_1.2.0~b2-2+deb10u1.debian.tar.xz
11ebe5330963236a2bf45521d38e6e6f2cdd61b5 7400 waitress_1.2.0~b2-2+deb10u1_source.buildinfo
Checksums-Sha256:
539e80539e1cc4f6518edca82851e8e66a400a8513b24ef448a09f0cb064f7a3 1643 waitress_1.2.0~b2-2+deb10u1.dsc
cdd45fc341b4972ec9f51cf3477f41fc84832bcedc9467a4e6a35d35fdf3e245 156556 waitress_1.2.0~b2.orig.tar.gz
fd474f3d5bc77b1b882f3137a73a090d0f0894a1c8714101124303c0cb2ecf26 22276 waitress_1.2.0~b2-2+deb10u1.debian.tar.xz
eded290fa3dd43a83527c6b8cbd1738bca07e3dbf9476be42cc93c4824590dc7 7400 waitress_1.2.0~b2-2+deb10u1_source.buildinfo
Files:
c4f3813bb1b6215738b486a4080d4cda 1643 python optional waitress_1.2.0~b2-2+deb10u1.dsc
db9f9a12cf177fd3a6419205a0202f4d 156556 python optional waitress_1.2.0~b2.orig.tar.gz
f1441c82cfed78a2c3c4c1abde9951d7 22276 python optional waitress_1.2.0~b2-2+deb10u1.debian.tar.xz
ad7de420a58af500a2f5edd563f46371 7400 python optional waitress_1.2.0~b2-2+deb10u1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iIoEARYKADIWIQTumtb5BSD6EfafSCRHew2wJjpU2AUCYn7H+BQcc3RlZmFub3JA
ZGViaWFuLm9yZwAKCRBHew2wJjpU2HDkAP9n2x4AaqJ6AzBai299e61Heg9H31nZ
+iyo3WeLVgLjOgD+JRKbybt+5dOj4tu7X42G6/tyYb5UfRErQln9qc7klws=
=s5dj
-----END PGP SIGNATURE-----
Reply to: