Re: Linux blind TCP spoofing, act II + others
A secure patch is work in progress thanks to precious advices from Solar Designer and Theo de Raadt. I'll send this patch to bugtraq when done. Please, if you are some good links about how to is possible to compute N for 'X^2 mod N' generator in real-time or links about others hard to predict RNG send me an email. antirez On Sat, Aug 07, 1999 at 09:58:10AM -0700, David Wagner wrote: In article [EMAIL PROTECTED], Salvatore Sanfilippo -antirez- [EMAIL PROTECTED] wrote: i think that a consecutive IP id now can be considered a weakness in IP stacks. [...] Here is a patch for linux 2.0.36 [...] 'Truly random id' [...] Your patch isn't secure. It uses a weak pseudo-random number generator to generate id's, and an attacker can just crack the PRNG to predict what id's will be used in the future. I think you probably want to use /dev/urandom to generate your IP id's, to prevent this attack. (Or use a variant of Bellovin's RFC 1948, adapted to generate IP id's instead of TCP ISN's.) -- Salvatore Sanfilippo [EMAIL PROTECTED] [EMAIL PROTECTED] ALICOM snc Tel: +39-0871-403522 Fax: +39-0871-41960 Web: www.alicom.com try hping: http://www.kyuzz.org/antirez FreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBarald
Re: Linux blind TCP spoofing, act II + others
On Sun, Aug 01, 1999 at 01:10:06AM +0200, Nergal wrote: 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 enables anyone to determine the number of packets sent by host A: it's enough to ping it, note the value of ID field of received ICMP_REPLY packet, wait x seconds (or perform some other actions), then again ping host A. The difference between ID fields of received ICMP_REPLY packets is equal to (the number of packets sent by A in x second) +1. "Idle portscan" by antirez uses this technique. Re, i think that a consecutive IP id now can be considered a weakness in IP stacks. Using it you today are able at least to scan spoofed, to guess host traffic and you can use it when you need to know if the target host of your spoofed packet answered. Here is a patch for linux 2.0.36, maybe it isn't SMP safe so don't use it if your linux box have more than one CPU. Note: the name of this patch are 'True random id', however this isn't true, a better name is 'Truly random id'. There are a lot of 'better possible patchs' to fix this problem, but this patch is old and writed in 30 min. so i'm interested in your comment about how to implement a better patch. Without having done an analysis of the pseudo-random number generator in the Linux patch provided, I have a few comments to make. This situation is very similar to the resolver problem. For a reminder about the resolver issue we were solving, see http://www.openbsd.org/advisories/res_random Wow. April 22, 1997. That's before OpenBSD 2.1 was released, you know, the release that was almost impossible to install from CD... OpenBSD 2.5 solves this by using the same non-repeating random number generator that we used to solve the resolver problem. The same code simply gets moved into the kernel. Basically, you do not want to make that field random using a stock random number generator, as close repeats (same number repeated in close proximity to a previous occurance) can cause grotesque errors in fragment reassembly at the destination. The existing method of using ip_id++, avoids such problems as well as they can be avoided in a 16-bit identifier space. If you don't believe me, heck, just set the ip_id to 31337 each time and see how well IP de-fragmentation suddenly works.. Hence, what you really want is a pseudo random number generator which is fairly strong (in a 16 bit space, hah), but cleverly avoids re-using the same number in close proximity... I believe that this would solve your problem best. For more details, see: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_id.c?rev=1.1 In our case, this is called in the following places... netinet/ip_ip4.c:ipo-ip_id = ip_randomid(); netinet/ip_mroute.c:ip_copy-ip_id = ip_randomid(); netinet/ip_output.c:ip-ip_id = ip_randomid(); netinet/raw_ip.c: ip-ip_id = ip_randomid(); netinet6/ipv6_trans.c: ip-ip_id = ip_randomid(); Enjoy.
Re: Linux blind TCP spoofing, act II + others
It was put back into 2.0.35 because the "fix" caused interoperability problems with many other stacks. I've discussed those interoperability problems with Alan (thanks!), and have now updated my 2.0.37 patch to include a fix that shouldn't cause them any more: http://www.false.com/security/linux/ I must also thank Nergal for testing the patch. Signed, Solar Designer
Re: Linux blind TCP spoofing, act II + others
In article [EMAIL PROTECTED], Salvatore Sanfilippo -antirez- [EMAIL PROTECTED] wrote: i think that a consecutive IP id now can be considered a weakness in IP stacks. [...] Here is a patch for linux 2.0.36 [...] 'Truly random id' [...] Your patch isn't secure. It uses a weak pseudo-random number generator to generate id's, and an attacker can just crack the PRNG to predict what id's will be used in the future. I think you probably want to use /dev/urandom to generate your IP id's, to prevent this attack. (Or use a variant of Bellovin's RFC 1948, adapted to generate IP id's instead of TCP ISN's.)
Re: Linux blind TCP spoofing, act II + others
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 It was put back into 2.0.35 because the "fix" caused interoperability problems with many other stacks. Alan
Re: Linux blind TCP spoofing, act II + others
On Sun, Aug 01, 1999 at 01:10:06AM +0200, Nergal wrote: 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 enables anyone to determine the number of packets sent by host A: it's enough to ping it, note the value of ID field of received ICMP_REPLY packet, wait x seconds (or perform some other actions), then again ping host A. The difference between ID fields of received ICMP_REPLY packets is equal to (the number of packets sent by A in x second) +1. "Idle portscan" by antirez uses this technique. Re, i think that a consecutive IP id now can be considered a weakness in IP stacks. Using it you today are able at least to scan spoofed, to guess host traffic and you can use it when you need to know if the target host of your spoofed packet answered. Here is a patch for linux 2.0.36, maybe it isn't SMP safe so don't use it if your linux box have more than one CPU. Note: the name of this patch are 'True random id', however this isn't true, a better name is 'Truly random id'. There are a lot of 'better possible patchs' to fix this problem, but this patch is old and writed in 30 min. so i'm interested in your comment about how to implement a better patch. bye, antirez -- Salvatore Sanfilippo [EMAIL PROTECTED] [EMAIL PROTECTED] ALICOM snc Tel: +39-0871-403522 Fax: +39-0871-41960 Web: www.alicom.com try hping: http://www.kyuzz.org/antirez FreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBaraldiniFreeSilviaBarald diff -cr linux-2.0.36/Documentation/Configure.help linux-2.0.36-hack/Documentation/Configure.help *** linux-2.0.36/Documentation/Configure.help Sun Nov 15 19:32:42 1998 --- linux-2.0.36-hack/Documentation/Configure.help Sun Dec 27 15:48:18 1998 *** *** 1336,1341 --- 1336,1349 hence it is recommended that you say Y here unless you really know what you're doing. + IP: True random id + CONFIG_ID_RAND + This supplies true random ip id field in order to prevent id abuse + in port scanning and in outgoing packets traffic guessing. + See http://www.geek-girl.com/bugtraq/1998_4/0609.html for more + informations on this topic. + Warning: 256 Kbytes needed. + IP: Allow large windows (not recommend if 16MB of memory) CONFIG_SKB_LARGE On high speed, long distance networks the performance limit on diff -cr linux-2.0.36/net/ipv4/Config.in linux-2.0.36-hack/net/ipv4/Config.in *** linux-2.0.36/net/ipv4/Config.in Thu Jun 4 00:17:50 1998 --- linux-2.0.36-hack/net/ipv4/Config.inSun Dec 27 15:01:53 1998 *** *** 47,50 --- 47,51 bool 'IP: Disable Path MTU Discovery (normally enabled)' CONFIG_NO_PATH_MTU_DISCOVERY #bool 'IP: Disable NAGLE algorithm (normally enabled)' CONFIG_TCP_NAGLE_OFF bool 'IP: Drop source routed frames' CONFIG_IP_NOSR + bool 'IP: True random id' CONFIG_ID_RAND bool 'IP: Allow large windows (not recommended if 16Mb of memory)' CONFIG_SKB_LARGE diff -cr linux-2.0.36/net/ipv4/ip_forward.c linux-2.0.36-hack/net/ipv4/ip_forward.c *** linux-2.0.36/net/ipv4/ip_forward.c Thu Jun 4 00:17:50 1998 --- linux-2.0.36-hack/net/ipv4/ip_forward.c Sat Dec 26 21:47:15 1998 *** *** 77,83 --- 77,87 iph-protocol = IPPROTO_IPIP; iph-ihl= 5; iph-tot_len= htons(skb-len + len); /* Anand, ernet */ + #ifdef CONFIG_ID_RAND + iph-id = htons(getrandid()); + #else iph-id = htons(ip_id_count++); + #endif ip_send_check(iph); skb-dev = out; diff -cr linux-2.0.36/net/ipv4/ip_output.c linux-2.0.36-hack/net/ipv4/ip_output.c *** linux-2.0.36/net/ipv4/ip_output.c Thu Jun 4 00:17:50 1998 --- linux-2.0.36-hack/net/ipv4/ip_output.c Sun Dec 27 15:44:05 1998 *** *** 30,35 --- 30,36 *Juan Jose Ciarlante:sk/skb source address rewriting *Elena Apolinario Fdez de Sousa,:ipmr_forward never received multicast *Juan-Mariano de Goyeneche traffic generated locally. + *Salvatore Sanfilippo: IP id random. [EMAIL PROTECTED] */ #include asm/segment.h *** *** 265,271 --- 266,276 return mac; } + #ifdef CONFIG_ID_RAND + unsigned short getrandid(void); + #else int ip_id_count = 0; + #endif /* * This routine builds the appropriate hardware/IP headers for *** *** 483,489 --- 488,498 add_to_send_queue(sk, skb); /* fall through */ case 1: + #ifdef CONFIG_ID_RAND + iph-id = htons(getrandid()); + #else iph-id = htons(ip_id_count++); + #endif } skb-free = free;
