mailing list archives
RE: Identifying Kernel 2.4.x based Linux machines using UDP
From: "Fletcher, Stephen J" <stephen.fletcher () eds com>
Date: Thu, 21 Mar 2002 10:57:04 +1100
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.
From: Crist J. Clark [mailto:crist.clark () attbi com]
Sent: Wednesday, 20 March 2002 12:44 PM
To: Ofir Arkin
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
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