On Sun, Nov 24, 2002 at 11:29:58PM +0900, Takeharu Kato wrote: > Dear everyone: > > I'm trying to improve TCP sequence number generation algorithm in Linux > TCP/IP protocol stack now. > > According to CERT advisory, the Linux kernel has the predictable > TCP initial sequence number vulnerability > (http://www.cert.org/advisories/CA-2001-09.html). Err, no, according to the CERT advisory, the Linux kernel uses a variant of RFC 1948; it says nothing about Linux being vulnerable. > I experimentally adds codes to generate ISN with MD5 algorithm and > I examined it with NMAP version 3.0. The result of the examination > is shown in the last part of this mail. This show that MD5 algorithm > can generate more preferable ISN than the vanilla linux-2.4.19. Um, no... it doesn't say that either. Cutting and pasting from your own results, the difficulty level shows no change: > -- Linux-2.4.19-vanila(Plain version of Linux-2.4.19) > /usr/local/bin/nmap -sS -O -vv 192.168.0.1 > Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) > > Uptime 0.003 days (since Mon Nov 18 23:44:34 2002) > TCP Sequence Prediction: Class=random positive increments > Difficulty=2227511 (Good luck!) > TCP ISN Seq. Numbers: 13532D3F 14165923 13DC905D 1348808F 1340E1ED > 137C9D75 > IPID Sequence Generation: All zeros > -- TCP ISN calcuration with MD5 algorithm for Linux-2.4.19. > /usr/local/bin/nmap -sS -O -vv 192.168.0.1 > Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) > > TCP Sequence Prediction: Class=random positive increments > Difficulty=2227511 (Good luck!) > TCP ISN Seq. Numbers: 13532D3F 14165923 13DC905D 1348808F 1340E1ED > 137C9D75 > IPID Sequence Generation: All zeros > To solve this problem, I propose to use MD5 message digest algorithm to > calculate ISN, because MD5 is recommended algorithm to calculate it > in RFC1948. > > This algorithm may be inappropriate under the some circumstances > (e.g. Gigabit Ethernet network). Some people may prefer to use current > algorithm(it use a kind of MD4.). The Linux sequence number generator originally used MD5; and was the RFC 1948 algorithm. However, we moved from MD5 to a cut-down version of MD4 because it was causing significant performance issues on benchmarks using 100 megabit ethernet --- never mind gigabyte ethernets. > But Some people may regard the vulnerability as a serious one, so > I propose it as one of the kernel options for such peoples. Huh? Who? You're still vulnerable to TCP hijacking attacks if the attacker is on your local subnet, or on the network path between the client and the server. No use of a crypto hash for a checksum will change that. If you're concerned about TCP hijacking attacks, the only solution is real crypto; either ssh or IPSEC. The MD4 hash provides adequate protection for someone who is attempting a brute-force attack; although they can probably succeed within a day or so, or perhaps even in hours, that's still enough that that it won't be practical to attack a TCP connection in real time. If you can show a real-live attack which can be accomplished against the current MD4 checksum, please tell us. But the CERT advisory does not prove your contention; neither does the nmap output --- it says "Good Luck!" in both cases, which is American idiom which roughly translates to "it would be very difficult to carry out an attack based on guessing TCP sequence numbers". - Ted - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
