[24758] in bugtraq
Re: Identifying Kernel 2.4.x based Linux machines using UDP
daemon@ATHENA.MIT.EDU (Crist J. Clark)
Wed Mar 20 18:24:33 2002
Date: Tue, 19 Mar 2002 17:44:19 -0800
From: "Crist J. Clark" <crist.clark@attbi.com>
To: Ofir Arkin <ofir@stake.com>
Cc: bugtraq <bugtraq@securityfocus.com>
Message-ID: <20020319174419.D67739@blossom.cjclark.org>
Reply-To: cjclark@alum.mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C971D24.4070505@stake.com>; from ofir@stake.com on Tue, Mar 19, 2002 at 11:12:36AM +0000
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
