The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Red Hat Enterprise Linux - kernel: TCP-spoofed ghost ACKs and leak leak initial sequence number  Ubuntu     Linux - tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas     from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines:
    The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK     <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded     and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: If the ACK is a     duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK     > SND.NXT) then send an ACK, drop the segment, and return. The ignored above implies that the     processing of the incoming data segment continues, which means the ACK value is treated as acceptable.
    This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead     only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be     refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This     greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach     stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2     Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM,     IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0     listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14     the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet //     with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some     data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1     <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send     an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap     around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 -     1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack     3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and     prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001 (CVE-2023-52881)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2023-52881

medium Nessus Plugin ID 226507

Version 1.17