Applications that use the function EVPPKEYpubliccheck() to check RSA public keys may experience long delays. Where the key that is being checked has been obtained from an untrusted source this may lead to a Denial of Service. An application that calls EVPPKEYpubliccheck() and supplies an RSA key obtained from an untrusted source could be vulnerable to a Denial of Service attack.
The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. OpenSSL versions 3.0.0 to 3.0.12, 3.1.0 to 3.1.4 and 3.2.0 are vulnerable to this issue. OpenSSL versions 1.1.1 and 1.0.2 are not affected by this issue.
References: https://www.openssl.org/news/secadv/20240115.txt https://www.openwall.com/lists/oss-security/2024/01/15/2
Upstream fix: https://github.com/openssl/openssl/commit/18c02492138d1eb8b6548cb26e7b625fb2414a2a (3.0.13) https://github.com/openssl/openssl/commit/a830f551557d3d66a84bbb18a5b889c640c36294 (3.1.5) https://github.com/openssl/openssl/commit/0b0f7abfb37350794a4b8960fafc292cd5d1b84d (3.2.1)
heap-use-after-free in function strtoreg in vim/vim
Excessive time spent checking DSA keys and parameters
Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.
A vulnerability was found in cgroupreleaseagentwrite in kernel/cgroup/cgroup-v1.c in the Linux kernel. In this flaw, under certain circumstances, the cgroups v1 releaseagent feature can be used to escalate privilege and bypass namespace isolation unexpectedly.
Upstream Commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af
A race problem was seen in the vtkioctl in drivers/tty/vt/vtioctl.c in the Linux kernel, which may cause an out of bounds read in vt as the write access to vcmode is not protected by lock-in vtioctl (KDSETMDE). The highest threat from this vulnerability is to data confidentiality.
A flaw was found in the Linux kernel. The PTRACESEIZE code path allows attackers to bypass intended restrictions on setting the PTSUSPENDSECCOMP flag, possibly disabling seccomp.
DISPUTED In drivers/char/virtioconsole.c in the Linux kernel before 5.13.4, data corruption or loss can be triggered by an untrusted device that supplies a buf->len value exceeding the buffer size. NOTE: the vendor indicates that the cited data corruption is not a vulnerability in any existing use case; the length validation was added solely for robustness in the face of anomalous host OS behavior.
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.
Change to loop-limit adjustments introduced a possible overflow in the computation of loop limits.
Issue summary: Calling the OpenSSL API function SSLselectnextproto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer.
A use after free can have a range of potential consequences such as the corruption of valid data, crashes or execution of arbitrary code. However, only applications that directly call the SSLfreebuffers function are affected by this issue. Applications that do not call this function are not vulnerable. Our investigations indicate that this function is rarely used by applications.
The SSLfreebuffers function is used to free the internal OpenSSL buffer used when processing an incoming record from the network. The call is only expected to succeed if the buffer is not currently in use. However, two scenarios have been identified where the buffer is freed even when still in use.
The first scenario occurs where a record header has been received from the network and processed by OpenSSL, but the full record body has not yet arrived. In this case calling SSLfreebuffers will succeed even though a record has only been partially processed and the buffer is still in use.
The second scenario occurs where a full record containing application data has been received and processed by OpenSSL but the application has only read part of this data. Again a call to SSLfreebuffers will succeed even though the buffer is still in use.
While these scenarios could occur accidentally during normal operation a malicious attacker could attempt to engineer a stituation where this occurs. We are not aware of this issue being actively exploited.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
OpenSSL 1.0.2 is also not affected by this issue.
OpenSSL 3.3, 3.2, 3.1, 3.0 and 1.1.1 are vulnerable to this issue.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.1 once it is released.
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released.
OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released (premium support customers only).
Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit e5093133c3 (for 3.3), commit c88c3de510 (for 3.2), commit 704f725b96 (for 3.1) and commit b3f0eb0a29 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit f7a045f314 (for 1.1.1).
This issue was reported on 10th April 2024 by William Ahern (Akamai). The fix was developed by Matt Caswell and Watson Ladd (Akamai).
AMD. A buffer overflow issue was addressed with improved memory handling.
A vulnerability was discovered in Python. A quadratic algorithm exists when processing inputs to the IDNA (RFC 3490) decoder, such that a crafted unreasonably long name being presented to the decoder could lead to a CPU denial of service. Hostnames are often supplied by remote servers that could be controlled by a malicious actor, which could trigger excessive CPU consumption on the client attempting to make use of an attacker-supplied hostname.
A flaw was found in Python. The built-in modules httplib and http.client (included in Python 2 and Python 3, respectively) do not properly validate CRLF sequences in the HTTP request method, potentially allowing manipulation to the request by injecting additional HTTP headers. The highest threat from this vulnerability is to confidentiality and integrity.
A flaw was found in Python specifically within the urllib.parse module. This module helps break Uniform Resource Locator (URL) strings into components. The issue involves how the urlparse method does not sanitize input and allows characters like '\r' and '\n' in the URL path. This flaw allows an attacker to input a crafted URL leading to injection attacks. This flaw affects Python versions prior to 3.10.0b1 3.9.5 3.8.11 3.7.11 and 3.6.14.
Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes.
Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only "named curves" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low.
In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an "exotic" curve encoding.
The affected APIs include: ECGROUPnewcurveGF2m(), ECGROUPnewfromparams(), and various supporting BNGF2m() functions.
Applications working with "exotic" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation.
Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency.
There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.
The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue.
A use-after-free flaw was found in the Expat package, caused by destruction of a shared DTD in XMLExternalEntityParserCreate in out-of-memory situations. This may lead to availability disruptions.
A use-after-free flaw was found in usbsgcancel in drivers/usb/core/message.c in USB core subsystem. This flaw could allow a local attacker with special user privilege (or root) to crash the system due to a race problem in scatter-gather cancellation and transfer completion in usbsgwait. This vulnerability can even lead to a kernel information leak problem .
Here usbsgcancel() does not take any reference to the transfer and there is nothing to prevent the URBs from being deallocated while the routine is trying to use them.
Taking a reference by incrementing the transfer's io->count field while the cancellation is in progress and decrementing it afterwards can be way to address this. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. ~~~ BUG: KASAN: use-after-free in atomicread include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usbhcdunlinkurb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 ~~~
References: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.6.8 https://lkml.org/lkml/2020/3/23/52
Upstream commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=056ad39ee9253873522f6469c3364964a322912b
An issue was discovered in splithugepmd in mm/hugememory.c in the Linux kernel before 5.7.5. The copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check, aka CID-c444eb564fb1.
A security vulnerability was found in zlib. The flaw triggered a heap-based buffer in inflate in the inflate.c function via a large gzip header extra field. This flaw is only applicable in the call inflateGetHeader.
Abnormal termination of an application can a cause a denial of service.
Applications performing certificate name checks (e.g., TLS clients checking server certificates) may attempt to read an invalid memory address when comparing the expected name with an otherName subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program.
Note that basic certificate chain validation (signatures, dates, ...) is not affected, the denial of service can occur only when the application also specifies an expected DNS name, Email address or IP address.
TLS servers rarely solicit client certificates, and even when they do, they generally don't perform a name check against a "reference identifier" (expected identity), but rather extract the presented identity after checking the certificate chain. So TLS servers are generally not affected and the severity of the issue is Moderate.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.1.1 and 1.0.2 are also not affected by this issue.
OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.
OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2
OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3
OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15
A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBCTUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBCTUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.
Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions
A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.
Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSLVERIFYPEER verification mode is set.
Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients.
RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSLVERIFYPEER.
Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSLgetverifyresult(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2.
The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.
A flaw in the processing of received ICMP errors (ICMP fragment needed and ICMP redirect) in the Linux kernel functionality was found to allow the ability to quickly scan open UDP ports. This flaw allows an off-path remote user to effectively bypass the source port UDP randomization. The highest threat from this vulnerability is to confidentiality and possibly integrity, because software that relies on UDP source port randomization are indirectly affected as well.
A vulnerability was found in sgwrite in drivers/scsi/sg.c in SCSI generic (sg) driver subsystem. An attacker with a local access and special user privilege (or root) can cause a denial of service (DoS) if allocated list is not cleaned with invalid (Sgfd sfp) pointer at the time of failure, failing this can even cause a kernel internal information leak problem.
Reference and upstream commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83c6f2390040f188cc25b270b4befeb5628c1aee
gadgetdevdescUDCstore in drivers/usb/gadget/configfs.c in the Linux kernel 3.16 through 5.6.13 relies on kstrdup without considering the possibility of an internal '\0' value, which allows attackers to trigger an out-of-bounds read, aka CID-15753588bcd4.