Bugtraq mailing list archives
Re: Linux blind TCP spoofing, act II + others
From: solar () FALSE COM (Solar Designer)
Date: Thu, 5 Aug 1999 04:46:12 +0400
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
Current thread:
- Linux blind TCP spoofing, act II + others Nergal (Jul 31)
- Re: Linux blind TCP spoofing, act II + others Solar Designer (Aug 04)
- Re: Linux blind TCP spoofing, act II + others Alan Cox (Aug 06)
- Re: Linux blind TCP spoofing, act II + others Solar Designer (Aug 07)
- IRC: Exploit for a Bug in ircd2.10.x (qident) psychoid () GMX NET (Aug 07)
- FW1 UDP Port 0 DoS Malikai (Aug 09)
- Re: FW1 UDP Port 0 DoS Malikai (Aug 09)
- Re: Linux blind TCP spoofing, act II + others Alan Cox (Aug 06)
- Re: Linux blind TCP spoofing, act II + others Solar Designer (Aug 04)
- Re: Linux blind TCP spoofing, act II + others Salvatore Sanfilippo -antirez- (Aug 06)
- Re: Linux blind TCP spoofing, act II + others Theo de Raadt (Aug 07)
- Please pass the word: RAID registration deadlines! Gene Spafford (Aug 06)
- Crash FrontPage Remotely... Narr0w (Aug 07)
- Re: Linux blind TCP spoofing, act II + others David Wagner (Aug 07)