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
