The version of F5 Networks BIG-IP installed on the remote host is prior to 16.1.6 / 17.1.2.2 / 17.5.0. It is, therefore, affected by a vulnerability as referenced in the K000148479 advisory.

    In the Linux kernel, the following vulnerability has been resolved: 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 +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)

Tenable has extracted the preceding description block directly from the F5 Networks BIG-IP security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

Detections

Analytics

F5 Networks BIG-IP : Linux kernel vulnerability (K000148479)

high Nessus Plugin ID 210745

Version 1.3