netdev - Inadvertently sending a Christmas Tree TCP packet

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

Message-ID: <4FBFCFCA.2090501@ixiacom.com>
Date:	Fri, 25 May 2012 11:30:34 -0700
From:	Earl Chew <echew@...acom.com>
To:	<netdev@...r.kernel.org>
Subject: Inadvertently sending a Christmas Tree TCP packet

Does anyone have a reference to any discussions or patches that address this issue ?

Running a userspace daemon on a rather old 2.6.18 system can inadvertently cause a TCP
packet containing flags FIN, PSH, ACK and URG (see packet 16237) which can cause the receiver
(not Linux in this case) to become confused:

16220	111.075627	10.64.33.43	10.128.163.100	TCP	59253 > exec [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2
16222	0.203210	10.128.163.100	10.64.33.43	TCP	exec > 59253 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1250 WS=7
16223	0.000032	10.64.33.43	10.128.163.100	TCP	59253 > exec [ACK] Seq=1 Ack=1 Win=65532 Len=0
16224	0.000215	10.64.33.43	10.128.163.100	TCP	59253 > exec [PSH, ACK] Seq=1 Ack=1 Win=65532 Len=6
16225	0.202465	10.128.163.100	10.64.33.43	TCP	exec > 59253 [ACK] Seq=1 Ack=7 Win=5888 Len=0
16229	0.209383	10.64.33.43	10.128.163.100	TCP	59253 > exec [PSH, ACK] Seq=7 Ack=1 Win=65532 Len=9
16231	0.202573	10.128.163.100	10.64.33.43	TCP	exec > 59253 [ACK] Seq=1 Ack=16 Win=5888 Len=0
16232	0.000024	10.64.33.43	10.128.163.100	TCP	59253 > exec [PSH, ACK] Seq=16 Ack=1 Win=65532 Len=14
16233	0.202618	10.128.163.100	10.64.33.43	TCP	exec > 59253 [ACK] Seq=1 Ack=30 Win=5888 Len=0
16234	0.012718	10.128.163.100	10.64.33.43	TCP	exec > 59253 [PSH, ACK] Seq=1 Ack=30 Win=5888 Len=1
16235	0.101229	10.128.163.100	10.64.33.43	TCP	exec > 59253 [PSH, ACK] Seq=2 Ack=30 Win=5888 Len=29
16236	0.000032	10.64.33.43	10.128.163.100	TCP	59253 > exec [ACK] Seq=30 Ack=31 Win=65504 Len=0
16237	0.000319	10.128.163.100	10.64.33.43	TCP	exec > 59253 [FIN, PSH, ACK, URG] Seq=31 Ack=30 Win=5888 Urg=1 Len=1
16240	1.114085	10.128.163.100	10.64.33.43	TCP	[TCP Retransmission] exec > 59253 [FIN, PSH, ACK, URG] Seq=31 Ack=30 Win=5888 Urg=1 Len=1


The receiver has become confused, and the so the Linux sender retransmits at packet 16240, and continues retransmitting.
In this case, the application code at the receiver is blocked indefinitely trying to read a socket that seemingly
has (URG) data and yet at the same time doesn't have any more data (FIN).

Perhaps the making of a DOS attack ?


Earl


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html