https://linuxsecurity.com/advisories/deblts/debian-lts-dla-2056-1-waitress-security-update-08-52-57
CVE: (none) => CVE-2019-16789
Zombie, what's with the nonsensical bug titles lately? Anyway, there are two other CVEs fixed in 1.4.0, and the referenced one is fixed in 1.4.2. References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16785 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16786 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16789 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947433 https://lists.debian.org/debian-lts-announce/2020/01/msg00002.html https://www.debian.org/lts/security/2019/dla-2056
CC: (none) => geiger.david68210, jani.valimaaWhiteboard: (none) => MGA7TOOAssignee: bugsquad => mageiaVersion: 7 => CauldronSummary: Waitress did not properly validate that the HTTP headers it received were properly formed => python-waitress new security issues CVE-2019-1678[569]
Done for both Cauldron and mga7!
Advisory: ======================== Updated python-waitress packages fix security vulnerabilities: 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 (CVE-2019-16785). Waitress through version 1.3.1 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-16786). In Waitress through version 1.4.0, if a proxy server is used in front of waitress, an invalid request may be sent by an attacker that bypasses the front-end and is parsed differently by waitress leading to a potential for HTTP request smuggling. 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-16789). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16785 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16786 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16789 https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes ======================== Updated packages in core/updates_testing: ======================== python-waitress-1.4.2-1.mga7 python3-waitress-1.4.2-1.mga7 from python-waitress-1.4.2-1.mga7.src.rpm
Whiteboard: MGA7TOO => (none)Source RPM: python-waitress => python-waitress-1.2.1-1.mga7.src.rpmVersion: Cauldron => 7Assignee: mageia => qa-bugsCVE: CVE-2019-16789 => CVE-2019-1678[569]
Corrected Debian link: https://www.debian.org/lts/security/2020/dla-2056
MGA7-64 Plasma on Lenovo B50 No installation issues No previous updates on this, so tried to get some info from https://docs.pylonsproject.org/projects/waitress/en/stable/ but this is developer's stuff over my top. $ waitress-serve --help Usage: waitress-serve [OPTS] MODULE:OBJECT Standard options: --help Show this information. --call Call the given object to get the WSGI application. --host=ADDR Hostname or IP address on which to listen, default is '0.0.0.0', which means "all IP addresses on this host". Note: May not be used together with --listen --port=PORT TCP port on which to listen, default is '8080' Note: May not be used together with --listen --listen=ip:port Tell waitress to listen on an ip port combination. Example: --listen=127.0.0.1:8080 --listen=[::1]:8080 --listen=*:8080 etc..... $ waitress-serve --listen=127.0.0.1:8080 Error: Specify one application only I have no clue as to "MODULE:OBJECT" (well, I understand the general terms, but what these would hve to be in this case.......) Waiting for other info, before deciding on OK on clean install.
CC: (none) => herman.viaene
Trying to help here Herman but got into a "chicken and egg" situation because of lack of familiarity with python and WSGI. Tried to find out what WSGI means: Web Server Gateway Interface. ... It is used to forward requests from a web server (such as Apache or NGINX) to a backend Python web application or framework. Which does not help much. Found a reference to wsgiapp.py on GitHub - gunicorn. Used pip to install gunicorn then $ waitress-serve --listen=localhost:8080 gunicorn:wsgiapp Error: Bad module 'gunicorn' and then a Usage listing finishing off with: There was an exception (ImportError) importing your module. It had these arguments: 1. No module named gunicorn $ locate gunicorn /usr/lib/python3.7/site-packages/ansible/modules/web_infrastructure/gunicorn.py /usr/lib/python3.7/site-packages/ansible/modules/web_infrastructure/__pycache__/gunicorn.cpython-37.opt-1.pyc /usr/lib/python3.7/site-packages/ansible/modules/web_infrastructure/__pycache__/gunicorn.cpython-37.pyc Had a look at the wsgiapp.py code and saw this in the run() function: The ``gunicorn`` command line runner for launching Gunicorn with generic WSGI applications. Don't have a clue what all this is about. Not our territory Herman. Send it on.
CC: (none) => tarazed25
Installed python{,3}-gunicorn and ran that last command again and this time succeeded in finding gunicorn but failed on the attribute 'wsgiapp'. So, still clueless.
Thanks for giving it a good shot, guys. I'm sending this on on the basis of a clean install. Validating. Advisory in Comment 3.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_updateWhiteboard: (none) => MGA7-64-OK
CC: (none) => tmbKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0083.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
This update also fixed CVE-2019-16792: https://lists.suse.com/pipermail/sle-security-updates/2020-July/007124.html https://bugzilla.suse.com/show_bug.cgi?id=1161670