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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:04 PDT