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

[David Fifield <david () bamsoftware com>]

On Thu, Sep 10, 2009 at 09:43:53AM -0600, David Fifield wrote:
> 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.
> >
> > 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.

Thanks, Toby, for an excellent bug report and help debugging. I
committed the patch with your modification in r15424.

David Fifield

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