[UPDATED] Problem on Linux 2.4 with usage of ip_default_ttl

[Charles-Edouard Ruault <cruault@724.com>]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

attached is an updated patch fixing the following problem ( i missed one 
place where a change was needed in the patch that was posted yesterday ... )

--------------------------------original message -----------------------


Here's a small bug i've discovered yesterday in linux 2.4.18 :

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 ) and ICMP error messages
- TCP RST .

They instead use hardcoded values ( MAXTTL ).
 From what i've seen all the other IP packets are using the value set by
/proc/sys/net/ipv4/ip_default_ttl ( provided that the socket has been
created after changing the value ).

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....
By sending a few packets to the target host, you can see wether the
default ttl has been changed on the machine and therefore enforce other
findings about the host.

I've written a small patch ( against kernel 2.4.18 ) that fixes this
behaviour. I'm attaching it to this email.
comments are welcome.

PS : please CC me in replies to this email, i have not subscribed to the
list.


-- 
Charles-Edouard Ruault



[-- Attachment #2: default_ttl.patch.gz --]
[-- Type: application/x-gzip, Size: 711 bytes --]