Dear Linux Developers,
We're reaching out to you as part of the disclosure process of our research.
In our research, which we will present at IEEE Security & Privacy in May 2024, we found that attackers can not only create TCP-spoofed connections (which was already known), but can also reliably transmit IP-spoofed data over such connections. This has security implications for applications that rely on TCP endpoint IP addresses, such as firewalling or host-based authentication (e.g., SMTP/SPF, of DBs).
We basically discovered two TCP spoofing primitives. First, attackers can bruteforce the server-chosen send window by acknowledging data that was never sent (what we call "ghost ACKs"; see Figure 3 in the paper). Second, we show that there are side channels that allow the attacker to leak the otherwise-secret server-chosen initial sequence number (ISN). One of these side channels leverages TCP SYN cookies.
We believe that the TCP/IP stack can take countermeasures to prevent such attacks, or at least make them harder. For example, we think that TCP endpoints should ignore ghost ACKs, and have some ideas to randomize the TCP backlog queue to prevent the SYN cookie side channel.
At the same time, we have disclosed our findings to the IETF folks and hope that they have helpful feedback for us.
Heap-based buffer overflow in the DHCP client (udhcpc) in BusyBox before 1.25.0 allows remote attackers to have unspecified impact via vectors involving OPTION6RD parsing.
Improper input validation in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access.
Improper check for unusual or exceptional conditions in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access.
Improper check for unusual or exceptional conditions in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access.
Race condition in Seamless Firmware Updates for some Intel(R) reference platforms may allow a privileged user to potentially enable denial of service via local access.
Improper Isolation or Compartmentalization in the stream cache mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.
In the Linux kernel, the following vulnerability has been resolved:
mm: fix zswap writeback race condition
The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page.
The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B
The fix: Once the swap page cache has been allocated (case ZSWAPSWAPCACHENEW), zswap-shrink work just checks that the local zswapentry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data.
Reproducer: I originally found this by running stress overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/writtenbackpages should do the trick.
In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running stress --vm 1 --vm-bytes 300000000 --vm-stride 4000 makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/maxpoolpercent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set --vm-stride to something other than 4096 otherwise stress won't realize that memory has been corrupted because all pages would have the same data.
A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.
Validating the order of the public keys in the Diffie-Hellman Key Agreement Protocol, when an approved safe prime is used, allows remote attackers (from the client side) to trigger unnecessarily expensive server-side DHE modular-exponentiation calculations. The client may cause asymmetric resource consumption. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE and validate the order of the public key.
Accessibility. A privacy issue was addressed by removing sensitive data.
Quadratic complexity when parsing some invalid inputs in encoding/pem
Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate. This affects programs which validate arbitrary certificate chains.
A buffer overflow vulnerability in function gnuspecial in file cplus-dem.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.
paxdecodeheader in sparse.c in GNU Tar before 1.32 had a NULL pointer dereference when parsing certain archives that have malformed extended headers.
Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to enable information disclosure or denial of service via local access.
Improper access control in the BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.
Improper access control in the BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.
Improper input validation in the UEFI WheaERST module for some Intel(R) reference platforms may allow an escalation of privilege. System software adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.
In the Linux kernel, the following vulnerability has been resolved: mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B The fix: Once the swap page cache has been allocated (case ZSWAPSWAPCACHENEW), zswap-shrink work just checks that the local zswapentry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally found this by running stress overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/writtenbackpages should do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running stress --vm 1 --vm-bytes 300000000 --vm-stride 4000 makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/maxpoolpercent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set --vm-stride to something other than 4096 otherwise stress won't realize that memory has been corrupted because all pages would have the same data.
Validating the order of the public keys in the Diffie-Hellman Key Agreement Protocol, when an approved safe prime is used, allows remote attackers (from the client side) to trigger unnecessarily expensive server-side DHE modular-exponentiation calculations. The client may cause asymmetric resource consumption. The basic attack scenario is that the client must claim that it can only communicate with DHE, and the server must be configured to allow DHE and validate the order of the public key.
Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate. This affects programs which validate arbitrary certificate chains.
Improper input validation in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access.
Improper Isolation or Compartmentalization in the stream cache mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.
Improper conditions check in some Intel(R) Processors with Intel(R) SGX may allow a privileged user to potentially enable information disclosure via local access.
CVE-2024-39279 Insufficient granularity of access control in UEFI firmware in some Intel(R) processors may allow a authenticated user to potentially enable denial of service via local access. CVE-2024-28047 Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.
CVE-2024-39279 Insufficient granularity of access control in UEFI firmware in some Intel(R) processors may allow a authenticated user to potentially enable denial of service via local access. CVE-2024-28047 Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.
Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow.
Impact summary: Applications that use OBJobj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service.
CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.setnpnprotocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).
802.1X. An authentication issue was addressed with improved state management.