A null pointer dereference flaw was found in openssl. A remote attacker, able to control the arguments of the GENERALNAMEcmp function, could cause the application, compiled with openssl to crash resulting in a denial of service. The highest threat from this vulnerability is to system availability.
An unspecified error with CJK codec tests call eval() on content retrieved throug HTTP in multibytecodecsupport.py in Python has an unknown impact and attack vector.
A vulnerability was discovered in the PyYAML library in versions before 5.4, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the fullload method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. This flaw allows an attacker to execute arbitrary code on the system by abusing the python/object/new constructor. This flaw is due to an incomplete fix for CVE-2020-1747.
A flaw was found in python-pip. Installing remote packages is vulnerable to directory traversal via Content-Disposition header by a malicious server.
Upstream issue:
https://github.com/pypa/pip/issues/6413
A flaw was found in python-pip in the way it handled Unicode separators in git references. A remote attacker could possibly use this issue to install a different revision on a repository. The highest threat from this vulnerability is to data integrity.
A flaw was found in the SQL plugin shipped with Cyrus SASL. The vulnerability occurs due to failure to properly escape SQL input and leads to an improper input validation vulnerability. This flaw allows an attacker to execute arbitrary SQL commands and the ability to change the passwords for other accounts allowing escalation of privileges.
A flaw was found in libxml2. A call to the xmlGetID function can return a pointer already freed when parsing an XML document with the XMLPARSEDTDVALID option and without the XMLPARSENOENT option, resulting in a use-after-free issue.
Last updated 24 July 2024
A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
A vulnerability was found in Hibernate-Validator. The SafeHtml validator annotation fails to properly sanitize payloads consisting of potentially malicious code in HTML comments and instructions. This vulnerability can result in an XSS attack.
A heap-based buffer overflow was found in libxml2 when processing truncated UTF-8 input.
Reference: https://gitlab.gnome.org/GNOME/libxml2/-/issues/235
Upstream patch: https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2
Impact
The patches introduced to fix https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 were not complete and still would allow an attacker to smuggle requests/split a HTTP request with invalid data.
This updates the existing CVE with ID: CVE-2019-16789
Patches
Waitress version 1.4.2 has been updated to now validate HTTP headers better to avoid the issue, completely fixing all known issues with whitespace.
Workarounds
There are no work-arounds, upgrading to Waitress 1.4.2 is highly recommended.
References
See https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 for more information on the security issue.
For more information
If you have any questions or comments about this advisory:
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)
Impact
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.
According to the HTTP standard Transfer-Encoding should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with chunked.
Requests sent with:
Transfer-Encoding: gzip, chunked
Would incorrectly get ignored, and the request would use a Content-Length header instead to determine the body size of the HTTP message.
This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining.
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 will now return a 501 Not Implemented error if the Transfer-Encoding is not chunked or contains multiple elements. Waitress does not support any transfer codings such as gzip or deflate.
The Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don'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'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)
Impact
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.
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'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'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)
A flaw was found in python. A stack-based buffer overflow was discovered in the ctypes module provided within Python. Applications that use ctypes without carefully validating the input passed to it may be vulnerable to this flaw, which would allow an attacker to overflow a buffer on the stack and crash the application. The highest threat from this vulnerability is to system availability.
A flaw was found in python-cryptography, where it is vulnerable to Bleichenbacher timing attacks. This flaw allows an attacker, via the RSA decryption API, to decrypt parts of the ciphertext encrypted with RSA. The highest threat from this vulnerability is to confidentiality.
A buffer-overflow flaw was found in the python-cryptography package. In certain sequences of update() calls when symmetrically encrypting very large payloads (>2GB) could result in an integer overflow, leading to buffer overflows. Note: This fix is a workaround for the OpenSSL CVE-2021-23840 flaw. Source: pyca/cryptography project
HTTP header values do not have trailing OWS trimmed
An encoding error flaw exists in the Node.js code that is used to read a peer certificate in the TLS client authentication. An attacker can use this flaw to crash the process used to handle TLS client authentication.
DISPUTED In iconvdata/iso-2022-jp-3.c in the GNU C Library (aka glibc) 2.34, remote attackers can force iconv() to emit a spurious '\0' character via crafted ISO-2022-JP-3 data that is accompanied by an internal state reset. This may affect data integrity in certain iconv() use cases. NOTE: the vendor states "the bug cannot be invoked through user input and requires iconv to be invoked with a NULL inbuf, which ought to require a separate application bug to do so unintentionally. Hence there's no security impact to the bug."
In librt in the GNU C Library (aka glibc) through 2.34, sysdeps/unix/sysv/linux/mqnotify.c mishandles certain NOTIFYREMOVED data, leading to a NULL pointer dereference. NOTE: this vulnerability was introduced as a side effect of the CVE-2021-33574 fix.
GnuPG Libgcrypt could allow a remote attacker to obtain sensitive information, caused by improper handling of ElGamal encryption. By using side-channel attack techniques against mpipowm, and the window size, an attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.
A flaw was found in curl. The flaw lies in how curl handles cached or pipelined responses that it receives from either a IMAP, POP3, SMTP or FTP server before the TLS upgrade using STARTTLS. In such a scenario curl even after upgrading to TLS would trust these cached responses treating them as valid and authenticated and use them. An attacker could potentially use this flaw to carry out a Man-In-The-Middle attack. The highest threat from this vulnerability is to data confidentiality.
A flaw was found in curl. This flaw lies in the --ssl-reqd option or related settings in libcurl. Users specify this flag to upgrade to TLS when communicating with either IMAP, POP3 or a FTP server. An attacker controlling such servers could return a crafted response which could lead to curl client continue its operation without TLS encryption leading to data being transmitted in clear text over the network. The highest threat from this vulnerability is to data confidentiality.
A use-after-free flaw was found in the way curl handled TLS session data. The curl versions using the OpenSSL library as their TLS backend could use freed memory after TLS session renegotiation was performed by the OpenSSL library. A malicious TLS server could use this flaw to crash or, possibly, execute arbitrary code with the privileges of a client application using the curl library.
A flaw was found in the way curl handled telnet protocol option for sending environment variables, which could lead to sending of uninitialized data from a stack-based buffer to the server. This issue leads to potentially revealing sensitive internal information to the server using a clear-text network protocol.
curl 7.61.0 through 7.76.1 suffers from exposure of data element to wrong session due to a mistake in the code for CURLOPTSSLCIPHERLIST when libcurl is built to use the Schannel TLS library. The selected cipher set was stored in a single "static" variable in the library, which has the surprising side-effect that if an application sets up multiple concurrent transfers, the last one that sets the ciphers will accidentally control the set used by all transfers. In a worst-case scenario, this weakens transport security significantly.
A NULL pointer dereference flaw was found in libxml2, where it did not propagate errors while parsing XML mixed content. This flaw causes the application to crash if an untrusted XML document is parsed in recovery mode and post validated. The highest threat from this vulnerability is to system availability.
ActionKit. An input validation issue was addressed with improved input validation.
GNOME libxml2 is vulnerable to a buffer overflow, caused by improper bounds checking by the xmlEncodeEntitiesInternal function in libxml2/entities.c. By persuading a victim to open a specially-crafted file, a remote attacker could overflow a buffer and execute arbitrary code on the system.