Re: bug printing OS information if lastboot is reported in the future

[David Fifield <david () bamsoftware com>]

On Thu, Sep 10, 2009 at 09:10:51AM -0600, David Fifield wrote:
> On Wed, Sep 09, 2009 at 01:58:07PM -0500, Toby Simmons wrote:
> > Sorry, I've never reported a bug before ... I hope I'm doing this right ...
> >
> > Running on Windows XP sp 3
> > Using the arguments:
> > -sS -sV -T4 -O -v --osscan-limit --version-light 10.2.2.200 -oX
> > c:\temp\p.xml
> >
> > Where 10.2.2.200 is a 10.3.9 Mac OS X that (for some unknown reason) seems
> > to return it's lastboot in the future after running an OS scan.
> >
> > Crash occurs when trying to output the uptime to an XML log.
>
> Thanks for the good bug report. OS X boxes randomize their initial TCP
> timestamp, so the uptime and lastboot guesses are meaningless. (OS X is
> why we started labeling the fields a "guess".) If you reboot the machine
> it will start giving a totally different, and still incorrect, lastboot.
>
> I think there are two problems here. The first is the lastboot of
> 3823319248. This is a 32-bit unsigned integer overflow in the lastboot
> calculation. It could happen here in osscan2.cc:
>
>     if (avg_ts_hz > 0 && avg_ts_hz < 5.66) { /* relatively wide range because sampling time so short and frequency so 
> slow */
>       hss->si.ts_seqclass = TS_SEQ_2HZ;
>       hss->si.lastboot = hss->seq_send_times[0].tv_sec - (hss->si.timestamps[0] / 2);
>     }
>
> If the current time is 1252519807 and the returned timestamp is
> 3448335710 (which it may be because it is random), then the lastboot
> would be calculated to be -471648048 (1955-01-20 19:39:12), which when
> put in an unsigned 32-bit variable becomes the value you saw, 3823319248
> (2091-02-26 03:07:28).
>
> The second issue is that in the log output we're doing a subtraction
> with a variable of type time_t, which must be 64 bits on your platform.
> I don't think changing the format specifier to %lli will work on 32-bit
> platforms. Instead we should make lastboot have the same type as the
> tv_sec member of struct timeval, namely long int.
>
> You seem to have a development environment set up; I'll send you a patch
> to try. Don't reboot the Mac machine yet.

Here's the patch to try. The uptime calculation is done with doubles so
as not to overflow. Negative times will be caught by the usual logic
that discards uptimes that appear to be over two years.

David Fifield

Attachment: lastboot-overflow.diff
Description:

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