netdev - Incoming TCP packet validation (of 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>] [day] [month] [year] [list]

Message-ID: <CALvgte9rOwNtzUTzXAM4sOVnoMyM=MZ9Wm+WXGvEaSidcnB0+w@mail.gmail.com>
Date:   Sat, 27 Jan 2018 21:22:55 -0800
From:   Zhiyun Qian <zhiyunq@...ucr.edu>
To:     netdev@...r.kernel.org
Subject: Incoming TCP packet validation (of ACK numbers)

Hi there,

As part of our ongoing research effort to understand the discrepancies
among Linux, macOS (FreeBSD), and Windows. We discover a violation of
the way Linux hanldes incoming TCP packet, specifically ACK number
validation.

According to RFC 793, "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".
In RFC 5961, the first sentence is changed (for more stringent ACK
number validation) but the second sentence remains the same.

Clearly, when the ACK number of the incoming packet is larger than
SND.NXT, we are supposed to send back an ACK. However, Linux currently
chooses to silently discard the packet without any reply. We have
checked macOS implementation which adheres to the specification.

I'd love to hear any thoughts on this.

Best,
-Zhiyun