CVE-2022-23219 – glibc: Stack-based buffer overflow in sunrpc clnt_create via a long pathname
https://notcve.org/view.php?id=CVE-2022-23219
The deprecated compatibility function clnt_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution. La función de compatibilidad obsoleta clnt_create en el módulo sunrpc de la Biblioteca C de GNU (también se conoce como glibc) versiones hasta 2.34, copia su argumento de nombre de host en la pila sin comprobar su longitud, que puede resultar en un desbordamiento de búfer, resultando potencialmente en una denegación de servicio o (si una aplicación no está construida con un protector de pila habilitado) la ejecución de código arbitrario A stack based buffer-overflow vulnerability was found in the deprecated compatibility function clnt_create() in the sunrpc's clnt_gen.c module of the GNU C Library (aka glibc) through 2.34. This vulnerability copies its hostname argument onto the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) lead to arbitrary code execution. • https://lists.debian.org/debian-lts-announce/2022/10/msg00021.html https://security.gentoo.org/glsa/202208-24 https://sourceware.org/bugzilla/show_bug.cgi?id=22542 https://www.oracle.com/security-alerts/cpujul2022.html https://access.redhat.com/security/cve/CVE-2022-23219 https://bugzilla.redhat.com/show_bug.cgi?id=2042017 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •
CVE-2021-45105 – Apache Log4j2 does not always protect from infinite recursion in lookup evaluation
https://notcve.org/view.php?id=CVE-2021-45105
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1. Apache Log4j2 versiones 2.0-alpha1 hasta 2.16.0 (excluyendo las versiones 2.12.3 y 2.3.1) no protegían de la recursión no controlada de las búsquedas autorreferenciales. Esto permite a un atacante con control sobre los datos de Thread Context Map causar una denegación de servicio cuando es interpretada una cadena diseñada. • https://github.com/thedevappsecguy/Log4J-Mitigation-CVE-2021-44228--CVE-2021-45046--CVE-2021-45105--CVE-2021-44832 https://github.com/tejas-nagchandi/CVE-2021-45105 https://github.com/pravin-pp/log4j2-CVE-2021-45105 https://github.com/dileepdkumar/https-github.com-pravin-pp-log4j2-CVE-2021-45105-1 https://github.com/dileepdkumar/https-github.com-pravin-pp-log4j2-CVE-2021-45105 https://github.com/dileepdkumar/https-github.com-dileepdkumar-https-github.com-pravin-pp-log4j2-CVE-2021-45105-v htt • CWE-20: Improper Input Validation CWE-674: Uncontrolled Recursion •
CVE-2021-4104 – Deserialization of untrusted data in JMSAppender in Apache Log4j 1.2
https://notcve.org/view.php?id=CVE-2021-4104
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions. • http://www.openwall.com/lists/oss-security/2022/01/18/3 https://access.redhat.com/security/cve/CVE-2021-4104 https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0033 https://security.gentoo.org/glsa/202209-02 https://security.gentoo.org/glsa/202310-16 https://security.gentoo.org/glsa/202312-02 https://security.gentoo.org/glsa/202312-04 https://security.netapp.com/advisory/ntap-20211223-0007 https • CWE-20: Improper Input Validation CWE-502: Deserialization of Untrusted Data •
CVE-2021-43797 – HTTP fails to validate against control chars in header names which may lead to HTTP request smuggling
https://notcve.org/view.php?id=CVE-2021-43797
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Netty prior to version 4.1.71.Final skips control chars when they are present at the beginning / end of the header name. It should instead fail fast as these are not allowed by the spec and could lead to HTTP request smuggling. Failing to do the validation might cause netty to "sanitize" header names before it forward these to another remote system when used as proxy. This remote system can't see the invalid usage anymore, and therefore does not do the validation itself. • https://github.com/netty/netty/commit/07aa6b5938a8b6ed7a6586e066400e2643897323 https://github.com/netty/netty/security/advisories/GHSA-wx5j-54mm-rqqq https://lists.debian.org/debian-lts-announce/2023/01/msg00008.html https://security.netapp.com/advisory/ntap-20220107-0003 https://www.debian.org/security/2023/dsa-5316 https://www.oracle.com/security-alerts/cpuapr2022.html https://www.oracle.com/security-alerts/cpujul2022.html https://access.redhat.com/security/cve/CVE-2021-43797 https://bugzilla • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVE-2021-43396
https://notcve.org/view.php?id=CVE-2021-43396
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. ** EN DISPUTA ** En el archivo iconvdata/iso-2022-jp-3.c de la Biblioteca C de GNU (también conocida como glibc) 2.34, los atacantes remotos pueden forzar a iconv() a emitir un carácter espurio '\0' a través de datos ISO-2022-JP-3 manipulados que van acompañados de un reinicio de estado interno. Esto puede afectar a la integridad de los datos en ciertos casos de uso de iconv(). • https://blog.tuxcare.com/vulnerability/vulnerability-in-iconv-identified-by-tuxcare-team-cve-2021-43396 https://sourceware.org/bugzilla/show_bug.cgi?id=28524 https://sourceware.org/git/?p=glibc.git%3Ba=commit%3Bh=ff012870b2c02a62598c04daa1e54632e020fd7d https://www.oracle.com/security-alerts/cpujul2022.html •