Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - tcp不接受从未发送的字节的 ACK 此修补程序基于 Yepeng Pan 和 Christian Rossow 的详细报告以及想法。ACK seq 验证当前遵循 RFC 5961 5.2 指南：仅当 ACK 值在 ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) 范围内时，才视为可以接受。必须丢弃 ACK 值不满足上述条件的所有传入分段，并发回 ACK。需要注意的是，RFC 793 第 72 页（第五次检查）中指出： 如果 ACK 重复 (SEG.ACK < SND.UNA)，则可将其忽略。如果 ACK 确认尚未发送的内容 (SEG.ACK > SND.NXT)，则发送 ACK，丢弃该报文段，然后返回。上述忽略表示传入数据段的处理会继续，即 ACK 值视为可接受。
    此缓解措施使 ACK 检查更严格因为不会接受任何 ACK < SND.UNA 而是只接受 ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND 范围内的 ACK。 NXT) 拨通。通过不接受从未发送的字节的 ACK，可以针对新的（可能还有欺骗的）流优化此问题。这样做可以极低成本大幅提高 TCP 的安全性。我添加了 Fixes: 标签以确保此修补程序将接触到稳定的树即使“blamed”修补程序遵守 RFC。 tp->bytes_acked 已添加到 linux-4.2 中以下 packetdrill 测试由 Yepeng Pan 提供显示当前问题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 // ----------------握手 ------------------- // // 当窗口缩放比例设置为 14 时窗口大小可扩展为 // 65535 * (2^14) = 1073725440。Linux 接受 ack 编号格式为 (Server_ISN+1-1073725440) 的 ACK 数据包。Server_ISN+1) // 尽管此确认编号确认服务器从未发送的某些数据。 +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 // 对于已建立的连接我们发送了 ACK 数据包 // ack 数据包使用 ack 编号 1 - 1073725300 + 2^32, // 其中 2^32 用于环绕。 // 注意我们使用 1073725300 代替 1073725440 以避免可能的 // 边缘情况。 // 1 - 1073725300 + 2^32 = 3221241997 // 糟糕旧内核可接受此数据包。 +0 < 。 1:1001(1000) ack 3221241997 win 65535 // 在内核修复之后以下内容将被替换为质询 ACK/ // 并且之前的恶意帧将被丢弃。 +0 > 。 1:1(0) ack 1001 (CVE-2023-52881)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2023-52881

medium Nessus 插件 ID 226507

版本 1.17