I believe this was implemented with the ZeroCopy patch. Setting the sequence number was removed where not needed to speed things up, which was the main function of the ZeroCopy patch. The patch was included in the main tree somewhere around 2.4.8. Regards Stephen -----Original Message----- From: Crist J. Clark [mailto:crist.clark@attbi.com] Sent: Wednesday, 20 March 2002 12:44 PM To: Ofir Arkin Cc: bugtraq Subject: Re: Identifying Kernel 2.4.x based Linux machines using UDP On Tue, Mar 19, 2002 at 11:12:36AM +0000, Ofir Arkin wrote: > Subject: Identifying Kernel 2.4.x based Linux machines using UDP > > Author: Ofir Arkin (ofir@atstake.com) > > > Linux Kernel 2.4.x has a bug with the UDP implementation which allows > both active and passive fingerprinting of Linux machines based on the > 2.4.x Kernel. This is a feature, not a bug. (IIRC, I am not a Linux developer and do not follow the Linux IP stack development.) > The following is a simple nslookup query initiated from my Kernel 2.4.10 > based Linux machine: > > 03/16-11:49:41.531642 192.168.1.200:1024 -> x.x.x.x:53 UDP TTL:64 > TOS:0x0 ID:0 IpLen:20 DgmLen:63 DF ^ ^^ Note that the "Do not Fragment" bit is set. The sole purpose of the IP ID field is to assist in the reassembly of fragmented datagrams. If the packet cannot be fragmented, the IP ID field is useless. The Linux IP stack designers have chosen to use a zero IP ID field when the DF bit is set. I am not a Linux IP developer, but I can think of several arguments to do this. If you are really concerned with IP ID randomness (and strangely enough, some people are), algorthims which produce "good" random numbers tend to be computationally expensive. Why waste the computations on the IP ID when it will never be used in DF packets? Right now, Linux kernels are one of the few to do this, so it is a way to fingerprint. But most everyone on this list knows fingerprinting is usually very easy anyway and is not vulnerability per sae. Also consider that other IP implementations may change to this behavior in the future as it does make some sense. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org
