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

[David Fifield <david () bamsoftware com>]

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.
>
> (line 1940 of nmap.cc)
>       printosscanoutput(currenths);
>  
> Jumps to (line 1714 of output.cc)
>     log_write(LOG_XML, "<uptime seconds=\"%li\" lastboot=\"%s\" />\n",
> tv.tv_sec - currenths->seq.lastboot, tmbuf);
>
>    (tv.tv_sec = 1252519807; currenths->seq.lastboot = 3823319248; tmbuf =
> "Mon Feb 26 03:07:28 2091")
>
> Jumps to (line 1092 of output.cc)
>       log_vwrite(l, fmt, ap);
>
> Jumps to (line 1043 of output.cc)
>       len = Vsnprintf(writebuf, writebuflen, fmt, ap);
>
> Jumps to (line 145 of nbase_str.c)
>       ret = vsnprintf(s, n, fmt, ap);
>
> --- MS code now ---
> Jumps to (line 190 of VC\crt\src\vsprintf.c)
>     return _vsnprintf_l(string, count, format, NULL, ap);
>
> Jumps to (line 138 of VC\crt\src\vsprintf.c)
>         retval = _output_l(outfile, format, plocinfo, ap );
>
> Jumps to (eventually, line 1589 of VC\crt\src\output.c where something weird
> happens in this line)
>    text.sz = (char *)get_ptr_arg(&argptr);
>
> text.sz ends up being a bad pointer (0xffffffff)

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.

David Fifield

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