Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Identifying Kernel 2.4.x based Linux machines using UDP
From: Charles-Edouard Ruault <cruault () 724 com>
Date: Tue, 19 Mar 2002 11:09:05 -0800


now that you're bringing the subject on the table, i'll follow up with a small bug i've discovered yesterday ... On Linux you can "customize" the default ttl that will be used in all the IP packets that the box will be sending ( using /proc/sys/net/ipv4/ip_default_ttl ) . One of the main reasons to do that , as it has been said in many articles, is to make your machine a little bit more difficult to fingerprint. However, while playing with this feature, i've discovered that the current kernel ( 2.4.18 ) and probably earlier versions, don't use this default value when generating the following packets :

- ICMP reply ( of any kind )

Therefore, changing the ip_default_ttl on a standard kernel might do the opposite of what you're trying to achieve : make it much easier for an attacker to fingerprint your os....

I've written a small patch ( against kernel 2.4.18 ) that fixes this behaviour. I'm attaching it to this email ( i've also posted in on the linux-kernel mailing list ).
comments are welcome.

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.

The following is a simple nslookup query initiated from my Kernel 2.4.10 based Linux machine:

03/16-11:49:41.531642 -> x.x.x.x:53 UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:63 DF
Len: 43
BC 0D 01 00 00 01 00 00 00 00 00 00 03 77 77 77  .............www
03 63 6E 6E 03 63 6F 6D 05 6C 6F 63 61 6C 00 00  .cnn.com.local..
01 00 01                                         ...

The IP Identification field value with the UDP datagram is zero (0). The value will be constant and will not be changed for future UDP datagrams I will be sending.

The problem is not only with generating UDP datagrams, but also with answering UDP queries. With the following example I have sent a UDP datagram to the ECHO service on a Linux 2.4.18 based machine:

03/16-12:13:17.388211 -> y.y.y.y:7
UDP TTL:64 TOS:0x0 ID:28256 IpLen:20 DgmLen:28
Len: 8

03/16-12:13:17.547636 y.y.y.y:7 ->
UDP TTL:50 TOS:0x0 ID:0 IpLen:20 DgmLen:28 DF
Len: 8

The IP identification field value with the answer is zero (0). It will also be constant and will not changed if we further query the target.

The biggest problem is the ability to use legitimate applications, such as DNS queries with nslookup, and by sending and receiving one packet only to have the ability to fingerprint the 2.4.x Kernel branch.

The 2.2.x kernel branch seems not to be affected according to my tests.

Combined with another fingerprinting method using ICMP this time (http://www.sys-security.com/archive/bugtraq/ofirarkin2001-03.txt), we are able to fingerprint the 2.4.x kernel branch and divide it into two groups - 2.4.0-2.4.4 kernels, and the 2.4.5-2.4.18 kernels.

Charles-Edouard Ruault

Attachment: default_ttl.patch.gz

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]