Nmap Development mailing list archives
Re: bug printing OS information if lastboot is reported in the future
From: David Fifield <david () bamsoftware com>
Date: Thu, 10 Sep 2009 09:10:51 -0600
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
Current thread:
- bug printing OS information if lastboot is reported in the future Toby Simmons (Sep 10)
- Re: bug printing OS information if lastboot is reported in the future David Fifield (Sep 10)
- Re: bug printing OS information if lastboot is reported in the future David Fifield (Sep 10)
- Re: bug printing OS information if lastboot is reported in the future David Fifield (Sep 10)
- Re: bug printing OS information if lastboot is reported in the future David Fifield (Sep 10)
- Re: bug printing OS information if lastboot is reported in the future David Fifield (Sep 10)