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
On Tue, 2002-10-08 at 22:06, Roberto Nibali wrote:
> 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.
>
"When syncookies are enabled the packets are still answered and this
value [tcp_max_syn_backlog] is effectively ignored." -- From tcp(7)
manpage.
The whole point of syncookies is to negate the need for a backlog queue.
Or did I miss your point?
--
// Gianni Tedesco (gianni at ecsc dot co dot uk)
lynx --source http://www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D