Re: Linux blind TCP spoofing, act II + others

[solar () FALSE COM (Solar Designer)]

Hello,

> I notified kernel mantainers in May, but they didn't seem interested.

Perhaps everyone cares about 2.2 and 2.3 only these days.

>       So, when an attacker sends (as a third packet of tcp handshake) a
> packet with too small ack_seq, the server sends no packets (doesn't it
> violate RFC793 ?). When a packet with too big ack_seq is sent, the server
> sends a packet (with a reset flag).

I've first heard of this behavior from Coder's IP-spoof.2.  He didn't
realize this was a bug until I told him, though.

My secure-linux patch for 2.0.33 included a fix for this (and a few
other bugfixes, all enabled with its CONFIG_SECURE_BUGFIX option):

+#ifdef CONFIG_SECURE_BUGFIX
+       return 0;
+#else
        return 1;
+#endif

That's the last "return" in tcp_ack(), in linux/net/ipv4/tcp_input.c.
A zero return from tcp_ack() means a failed handshake, and generates
an RST packet.  Then 2.0.34 came out, and some of my bugfixes got in,
including this one.  From patch-2.0.34.gz:

-       return 1;
+       return 0;

So, the version of my patch for 2.0.34 didn't need to fix this any
more.  Of course, future updates of the patch I was making based on
the latest one, and never bothered to check for this bug again.

Now, after your post, I am looking at patch-2.0.35.gz:

-       return 0;
+       return 1;

So, the "feature" got re-introduced in 2.0.35.  I don't know of the
reason for this.  I can only guess that the other major TCP changes
in 2.0.35 were originally based on a version of the code older than
the one in 2.0.34, but only got into 2.0.35.  The other guess is, of
course, that this change caused problems in 2.0.34, but I doubt it.

>       Now let's recall another Linux feature. Many OSes (including Linux)
> assign to ID field of an outgoing IP datagram consecutive, increasing
> numbers (we forget about fragmentation here; irrelevant in this case). That

Somehow I didn't think of this at the time (was before this ID stuff
got to BugTraq), so I tried playing with packet count obtained from
the router via SNMP.  Never got my exploit reliable enough, though.

>       At the end of this post I enclosed an exploit; don't use it without
> the permission of the target host's admin. I tested it on 2.0.37, 36 and 30;
> probably all 2.0.x are affected. It requires libnet (which can be downloaded

Except for 2.0.34 and 2.0.33 with my patch, I believe.  I would
appreciate it if you could test the exploit on any of those, so that
I could put the fix back into my patch for 2.0.37.

Signed,
Solar Designer