Uptime estimates and TCP timestamp offsets

[David Fifield <david () bamsoftware com>]

Hi,

Fyodor asked me to look into why Nmap's estimate of uptime is way off on
some operating systems. For instance he told me that scanme.nmap.org has
been up for 147 days but Nmap reports its uptime as 47 days. Apart from
being inaccurate the uptime otherwise increases normally, i.e., it
increases by one day each day. This has been observed on Linux and Mac
OS X.

Nmap's estimate of uptime is based on a series of TCP timestamp
measurements. I found this patch to the Linux kernel that allows setting
an offset that is added to all timestamps:

http://lkml.org/lkml/2008/2/15/244

That would explain the observed behavior. However by doing a cursory
check of the current versions of certain files affected by the patch, it
doesn't appear to have been applied. Does anybody know? Maybe it has
been applied by individual distributions?

I scanned a Mac OS X 10.5.4 machine moments after booting it up. I
repeated the experiment four times, rebooting each time. I got

        Ignoring claimed uptime of 1219 days
        Ignoring claimed uptime of 1181 days
        Uptime: 644.073 days
        Ignoring claimed uptime of 871 days

So it certainly seems to be picking a random offset at boot.

What do we do? Nmap already throws out very long uptimes, but a
plausible uptime (like scanme's 47 days) can still be wrong. I don't
think there's a way to detect an operating system adding a random offset
to its timestamps, unless you scan across boots. Even though it can be
fooled, the uptime calculation isn't useless--it still works for most
OSs out there. Maybe just label it "Uptime guess"?

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org