netdev - Re: Non-standard TCP stack processing of packets with unacceptable ACK numbers

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1491838493.10587.14.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Mon, 10 Apr 2017 08:34:53 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Paul Fiterau Brostean <p.fiterau-brostean@...ence.ru.nl>
Cc:     netdev@...r.kernel.org, Frits Vaandrager <F.Vaandrager@...ru.nl>
Subject: Re: Non-standard TCP stack processing of packets with unacceptable
 ACK numbers

On Sat, 2017-04-08 at 22:29 +0200, Paul Fiterau Brostean wrote:
> Hello,
> 
> My name is Paul Fiterau, I am a PhD student at Radboud University whose 
> focus for the past few years has been among others to develop and apply 
> inference techniques on TCP stacks in order to obtain nice models, and 
> to verify them if possible using formal methods.  We contacted you on 
> something similar 2 years back.
> 
> The older (3.19 kernel release) Linux TCP stack we analyze exhibits 
> behavior that seems odd to me. The scenario is as follows (all packets 
> have empty payloads, no window scaling, rcv/snd window size should not 
> be a factor):
> 
>        TEST HARNESS (CLIENT)                        LINUX SERVER
> 
>    1.  -                                          LISTEN (server listen, then accepts)
> 
>    2.  - --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
> 
>    3.  - <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
> 
>    4.  - --> <SEQ=101><ACK=301><CTL=ACK>      --> ESTABLISHED
>   
>    5.  - <-- <SEQ=301><ACK=101><CTL=FIN,ACK>  <-- FIN WAIT-1 (server opts to close the data connection calling "close" on the connection socket)
> 
>    6.  - --> <SEQ=101><ACK=99999><CTL=FIN,ACK> --> CLOSING (client sends FIN,ACK with not yet sent acknowledgement number)
> 
>    7.  - <-- <SEQ=302><ACK=102><CTL=ACK>      <-- CLOSING (ACK is 102 instead of 101, why?)
>   
> ... (silence from CLIENT)
> 
>    8.  - <-- <SEQ=301><ACK=102><CTL=FIN,ACK>  <-- CLOSING (retransmission, again ACK is 102)
> 
> 
> Now, note that packet 6 while having the expected sequence number, 
> acknowledges something that wasn't sent by the server. So I would expect 
> the packet to maybe prompt an ACK response from the server, and then be 
> ignored. Yet it is not ignored and actually leads to an increase of the 
> acknowledgement number in the server's retransmission of the FIN,ACK 
> packet. The explanation I found is that the FIN  in packet 6 was 
> processed, despite the acknowledgement number being unacceptable. 
> Further experiments indeed show that the server processes this FIN, 
> transitioning to CLOSING, then on receiving an ACK for the FIN it had 
> send in packet 5, the server (or better said connection) transitions 
> from CLOSING to TIME_WAIT (as signaled by netstat).
> 
> 
> I attached a capture showing the scenario, as well as an equivalent 
> capture for a Windows 10 TCP server, which behaves exactly as I would 
> expect by  not increasing the expected sequence number after packet 6, 
> and thus not processing the FIN flag received.
> 
> I hope someone more knowledgeable can clear this up for me. Is it ok for 
> the server to process the FIN bit in a packet with an unacceptable 
> acknowledgement number? Could this be an inconsistency in the tested stack?

Hi Paul.

Thanks for your report, we will take a look at this today.