[Fwd: Re: [patch] tcp connection tracking 2.4.19]

[Fwd: Re: [patch] tcp connection tracking 2.4.19]

[Roberto Nibali]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Re: [patch] tcp connection tracking 2.4.19 --]
[-- Type: message/rfc822, Size: 4387 bytes --]

From: Roberto Nibali <ratz@drugphish.ch>
To: Martin Renold <martinxyz@gmx.ch>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] tcp connection tracking 2.4.19
Date: Tue, 08 Oct 2002 23:06:55 +0200
Message-ID: <3DA348EF.7060709@drugphish.ch>

Hello Martin,

> There is a bug in the stable 2.4.19 kernel in the ip_conntrack code that
> allows the final ACK of a SYN - SYN/ACK - ACK tcp handshake to establish
> an ASSURED connection even if it has a wrong sequence number. The current
> code only checks the ACK number.

Yes, and more than that. You can remove ESTABLISHED entries in the 
conntrack table by sending packets with the RST flag set and matching 
the template <srcIP, srcPORT, dstIP, dstPORT>.

> This allows a DoS attack that will make it impossible to establish *real*
> connections for some days, once the maximum is reached. Somebody sent me
> an exploit:

:) You should probably send stuff like that to the netfilter-devel ml. 
Besides that it isn't really an exploit.

> http://old.homeip.net/martin/cdos.tgz
> 
> So I wrote a simple patch against 2.4.19, but I must admit that I do not
> really understand the code around it, especially why it does not mark
> such a packet as invalid (I'm new to most things here).

You might want to take a look at the TCP window tracking patch which 
comes with the latest pom. It's part of the extra patches. This will 
solve the problems for you.

> diff -urN -X dontdiff kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
> --- kernel-source-2.4.19.origin/net/ipv4/netfilter/ip_conntrack_proto_tcp.c	Fri Oct  4 08:13:38 2002
> +++ kernel-source-2.4.19.patch/net/ipv4/netfilter/ip_conntrack_proto_tcp.c	Sat Oct  5 20:45:49 2002
> @@ -180,6 +180,8 @@
>  	if (oldtcpstate == TCP_CONNTRACK_SYN_SENT
>  	    && CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY
>  	    && tcph->syn && tcph->ack)
> +		conntrack->proto.tcp.handshake_seq
> +			= tcph->ack_seq;
>  		conntrack->proto.tcp.handshake_ack
>  			= htonl(ntohl(tcph->seq) + 1);
>  	WRITE_UNLOCK(&tcp_lock);
> @@ -196,6 +198,7 @@
>  		if (oldtcpstate == TCP_CONNTRACK_SYN_RECV
>  		    && CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL
>  		    && tcph->ack && !tcph->syn
> +		    && tcph->seq == conntrack->proto.tcp.handshake_seq
>  		    && tcph->ack_seq == conntrack->proto.tcp.handshake_ack)
>  			set_bit(IPS_ASSURED_BIT, &conntrack->status);
>  

Welcome to the world of almost-stateful packet filtering. Hey, other 
than that, the 3wahas 'exploit' is old. Also don't I understand why they 
claim that SYN cookies prevent syn flooding. Next time you meet someone 
of the guys, tell them about the backlog queue.

Cheers,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/