A flaw was found Go's net/http package. Servers using ReverseProxy from net/http in the Go standard library are vulnerable to a data race that results in a denial of service. The highest threat from this vulnerability is to system availability.
A flaw detected in golang: crypto/elliptic, in which P-224 keys as generated can return incorrect inputs, reducing the strength of the cryptography. The highest threat from this vulnerability is confidentiality and integrity.
Summary
Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.
Mitigations
To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.
Warning: To take effect, both the client and server must support this countermeasure.
As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.
Details
The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.
The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.
In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.
For more details see https://terrapin-attack.com.
Impact
This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.
In ISC BIND9 versions BIND 9.11.14 -> 9.11.19, BIND 9.14.9 -> 9.14.12, BIND 9.16.0 -> 9.16.3, BIND Supported Preview Edition 9.11.14-S1 -> 9.11.19-S1: Unless a nameserver is providing authoritative service for one or more zones and at least one zone contains an empty non-terminal entry containing an asterisk ("") character, this defect cannot be encountered. A would-be attacker who is allowed to change zone content could theoretically introduce such a record in order to exploit this condition to cause denial of service, though we consider the use of this vector unlikely because any such attack would require a significant privilege level and be easily traceable.
A flaw was found in bind. When flooding the target resolver with special queries, an attacker can significantly impair the resolver's performance, effectively denying legitimate clients access to the DNS resolution service.
An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause no confidentiality impact, low integrity impact, and no availability impact.
An unspecified vulnerability in Java SE related to the JAXP component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.
A flaw was found in the way the BMPImageReader class implementation in the ImageIO component of OpenJDK handled memory allocations when processing uncompressed BMP images. A specially-crafted BMP image with a small size could cause a Java application to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.
A flaw was found in the SSL logger implementation in the JSSE component of OpenJDK. A malicious client could cause a Java application acting as TLS server to raise an unexpected exception during TLS handshake.
An unspecified vulnerability in Java SE related to the JSSE component could allow an unauthenticated attacker to obtain sensitive information resulting in a high confidentiality impact using unknown attack vectors.
It was discovered that the Kerberos protocol implementation in the Libraries component of OpenJDK did not correctly report subject principals when using Kerberos Constrained Delegation. This could lead to the use of wrong Kerberos tickets.
A flaw was found in the way the Keytool component of OpenJDK handled X.509 certificates with validity period ending too far in the future, after year 9999. When such certificates were imported into a keystore, they could cause corruption of the keystore.
A flaw was found in the way the RTFReader class implementation in the Swing component of OpenJDK handled style keyword parameters. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFReader to allocate an excessive ammount of memory and possibly terminate on out-of-memory condition.
An inifinte loop flaw was found in the HttpsServer class implementation in the JSSE component of OpenJDK. A remote attacker could possibly use this flaw to cause a Java application implementing HTTPS server functionality to loop during the TLS session closing and consume an excessive amount of CPU time.
A flaw was found in the way the RTFParser class implementation in the Swing component of OpenJDK handled memory allocations. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFParser to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.
A CRLF injection flaw was found in the Lightweight HTTP Server component of OpenJDK. The HttpServer implementation did not restrict the use of CR and LF characters in values for HTTP headers, possibly allowing HTTP response splitting attacks.
A regular expression denial of service flaw was found in the Concurrency component of OpenJDK. The use of overly complex regular expressions in java.utils.Scanner could cause a high CPU usage when Scanner was used on parse certain inputs.
A flaw was found in the way the HashMap and the HashSet classes implementations in the Utility component of OpenJDK validated the load factor value during deserialization. A specially crafted serialized data stream could cause a Java application to allocate an excessive amount of memory and possibly terminate on out-of-memory condition when deserialized.
An unspecified vulnerability in Java SE related to the Hotspot component could allow an unauthenticated attacker to cause low confidentiality impact, low integrity impact, and no availability impact.
An unspecified vulnerability in Java SE could allow an unauthenticated attacker to obtain sensitive information resulting in a low confidentiality impact using unknown attack vectors.
A flaw was found in the way the TLS implementation in the JSSE component of OpenJDK re-used single null TLS sessions for new TLS connections. A remote attacker could possibly use this flaw to impact availability of a Java application providing TLS server.
Apache Tomcat is vulnerable to HTTP request smuggling, caused by a flaw when handling unusual Transfer-Encoding HTTP header. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.
Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; - Tomcat honoured the identify encoding; and - Tomcat did not ensure that, if present, the chunked encoding was the final encoding.
In the Linux kernel, the following vulnerability has been resolved:
PCI/PM: Drain runtime-idle callbacks before driver removal
A race condition between the .runtimeidle() callback and the .remove() callback in the rtsxpcr PCI driver leads to a kernel crash due to an unhandled page fault [1].
The problem is that rtsxpciruntimeidle() is not expected to be running after pmruntimegetsync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.
However, if a .runtimeidle() callback is already running when pmruntimegetsync() is called, the latter will notice that the runtime PM status of the device is RPMACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtimeidle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).
Thus in general, whoever is providing a .runtimeidle() callback needs to protect it from running in parallel with whatever code runs after pmruntimegetsync(). [Note that .runtimeidle() will not start after pmruntimegetsync() has returned, but it may continue running then if it has started earlier.]
One way to address that race condition is to call pmruntimebarrier() after pmruntimegetsync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtimeidle() callback to complete should it be running at that point. A suitable place for doing that is in pcideviceremove() which calls pmruntimegetsync() before removing the driver, so it may as well call pmruntimebarrier() subsequently, which will prevent the race in question from occurring, not just in the rtsxpcr driver, but in any PCI drivers providing .runtimeidle() callbacks.
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix corruption during on-line resize
The Linux kernel CVE team has assigned CVE-2024-35807 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35807-2a9e@gregkh/T
A flaw was found in the Linux kernel. A local attacker, able to inject conntrack netlink configuration, could overflow a local buffer causing crashes or triggering the use of incorrect protocol numbers in ctnetlinkparsetuplefilter in net/netfilter/nfconntracknetlink.c. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Accessibility. A privacy issue was addressed with improved private data redaction for log entries.
In libxml2 before 2.10.4, parsing of certain invalid XSD schemas can lead to a NULL pointer dereference and subsequently a segfault. This occurs in xmlSchemaFixupComplexType in xmlschemas.c.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel: Fix null ptr deref in btintelreadversion
If hcicmdsynccomplete() is triggered and skb is NULL, then hdev->reqskb is NULL, which will cause this issue.
In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).
Change multiplication to mulu32u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.