netdev - Re: TCP - Receiving unacceptable ACK in ESTABLISHED state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Thu, 13 Oct 2022 12:32:11 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Yakup Yıldız <yakup.yildiz@...lltech.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: TCP - Receiving unacceptable ACK in ESTABLISHED state

On Thu, Oct 13, 2022 at 12:10 PM Yakup Yıldız
<yakup.yildiz@...lltech.com> wrote:
>
> Hi,
>
> my name is Yakup Erdem Yildiz and I am currently working as an FPGA engineer at Bull Technology in Istanbul. We are working on a hardware TCP implementation and we are using some test scenarios to verify our hardware design.
>
> We applied the same scenarios on a Linux machine, which has the kernel release 5.4.0 and we found out that the Linux TCP does not behave properly in the following case, where "10.10.10.1" is the Linux machine under test.
>
>
>
> According to the RFC 9293, in a synchronized state TCP must send an empty ACK segment upon receiving a segment containing an unacceptable ACK number. Here in this case, no ACK is issued after receiving an unacceptable segment in ESTABLISHED state.
>
>
> -RFC 9293, p. 29
>
>    "If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSEWAIT,
>    CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out-of-window
>    sequence number or unacceptable acknowledgment number) must be responded to with an
>    empty acknowledgment segment (without any user data) containing the current send
>    sequence number and an acknowledgment indicating the next sequence number expected to
>    be received, and the connection remains in the same state."
>

We do not want to send an ACK for such a probe, coming from an attacker.
If the remote stack is that buggy, sending an ACK will not work around
the bug anyway.

I think the RFC 9293 (and RFC 793 3.9) spirit is to send ACK for old
ACKS, but not for ACK which are coming from the future (or very old
packets)

Also look for RFC 5961 recommendations if you implement a TCP stack.

> We wonder if this is a known issue, or is it an issue at all? We would be thankful if you can inform us about that.
>
> I also added the corresponding capture file as attachment.
>
> Regards,
>
> Yakup Erdem Yildiz
>
>