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: <46A3A0D5.6030909@potentialcash.com>
Date:	Sun, 22 Jul 2007 21:24:21 +0300
From:	john <john@...entialcash.com>
To:	netdev@...r.kernel.org
Subject: bug in tcp/ip stack

I tracked down something that appears to be a small bug in networking code.
The way in witch i can reproduce it a complex one but it works 100%, so 
here comes the details:

I noticed strange packets on my fw coming from mail server with RST/ACK 
flags set coming from source port with no one listening on it and no 
connection attempts made to them from outside.
There are few messages on forums describing same problem and calling 
them alien ACK/RST packets.

Postfix mail server gives this behavior if for some reason client resets 
connection but some packets from client arrives after the RST, the serer 
box responds with RST and then with RST/ACK (with the wrong source port 
number).

Here is packet dump

1    0.000000    10.0.0.254    10.0.0.68    TCP    50000 > smtp [SYN] 
Seq=0 Len=0
2    0.001036    10.0.0.68    10.0.0.254    TCP    smtp > 50000 [SYN, 
ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
3    0.001096    10.0.0.254    10.0.0.68    TCP    50000 > smtp [ACK] 
Seq=1 Ack=1 Win=1500 Len=0
4    0.001125    10.0.0.254    10.0.0.68    SMTP    Command: EHLO localhost
5    0.001150    10.0.0.254    10.0.0.68    TCP    50000 > smtp [RST] 
Seq=17 Len=0
6    0.001175    10.0.0.254    10.0.0.68    TCP    50000 > smtp [FIN, 
ACK] Seq=17 Ack=1 Win=1500 Len=0
7    0.001251    10.0.0.68    10.0.0.254    TCP    smtp > 50000 [ACK] 
Seq=1 Ack=17 Win=5840 Len=0
8    0.001284    10.0.0.68    10.0.0.254    TCP    smtp > 50000 [RST] 
Seq=1 Len=0
!!!9    0.218427    10.0.0.68    10.0.0.254    TCP    32768 > 50000 
[RST, ACK] Seq=0 Ack=0 Win=5840 Len=0

It is not the postfix bug, it is present in current 2.6.x and 2.4.x 
kernel versions but not in the 2.2.x tree, so after investigation i 
found it was introduced in 2.4.0-test9-pre3 back in year 2000 and 
survived for 7 years WOW :)


Whole 2.4.0-test9-pre3 diff is pretty big, but i managed to find lines 
responsible for this,
they are located in include/net/tcp.h

in function tcp_enter_cwr

if (sk->prev && !(sk->userlocks&SOCK_BINDPORT_LOCK))
                      tcp_put_port(sk);



It is not a big problem but under some setups the fw's conntrack table 
can get filled pretty quickly,  because wrong port number changes every 
time.

Can, you please check this out?

Evalds
-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ