Nmap Development mailing list archives
Re: Possible bug report - nmap scan elapsed time changes into negative time
From: Daniel Miller <bonsaiviking () gmail com>
Date: Fri, 25 Mar 2011 09:01:47 -0500
I looked into this some more. The particular function that affects that output line is NmapOps::TimeSinceStartMS, which returns an int generated with the TIMEVAL_MSEC_SUBTRACT macro #defined in nbase/nbase.h: #define TIMEVAL_MSEC_SUBTRACT(a,b) ((((a).tv_sec - (b).tv_sec) * 1000) + ((a).tv_usec - (b).tv_usec) / 1000) The overflow happens when the difference in seconds is multiplied by 1000. Interestingly, the TIMEVAL_SEC_SUBTRACT macro: #define TIMEVAL_SEC_SUBTRACT(a,b) ((a).tv_sec - (b).tv_sec + (((a).tv_usec < (b).tv_usec) ? - 1 : 0)) returns seconds, and does not suffer from this overflow. A quick grep through the source for calls to TimeSinceStartMS: $ find . \( -name .svn -prune -false \) -o -print0 | xargs -0 grep -H --color TimeSinceStartMS ./NmapOps.cc:int NmapOps::TimeSinceStartMS(const struct timeval *now) { ./osscan2.cc: (o.TimeSinceStartMS() - this->starttimems) / 1000.0, remain, ./osscan2.cc: OSI->starttimems = o.TimeSinceStartMS(); ./scan_engine.cc: // printf("SDELAY: increasing drops to %d (good: %d; tryno: %d, sent: %.4fs; prevSent: %.4fs, last_boost: %.4fs\n", hss->sdn.droppedRespSinceDelayChanged, hss->sdn.goodRespSinceDelayChanged, probe->tryno, o.TimeSinceStartMS(&probe->sent) / 1000.0, o.TimeSinceStartMS(&probe->prevSent) / 1000.0, o.TimeSinceStartMS(&hss->sdn.last_boost) / 1000.0); ./scan_engine.cc: log_write(LOG_PLAIN, "**TIMING STATS** (%.4fs): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, cwnd/ssthresh/delay, timeout/srtt/rttvar/\n", o.TimeSinceStartMS() / 1000.0); ./scan_engine.cc: // printf("TRACE: Finished doAnyNewProbes() at %.4fs\n", o TimeSinceStartMS(&USI->now) / 1000.0); ./scan_engine.cc: // printf("TRACE: Finished waitForResponses() at %.4fs\n", o.TimeSinceStartMS(&USI->now) / 1000.0); ./output.cc: int time = (int) (o.TimeSinceStartMS(&tv) / 1000.0); ./output.cc: xml_attribute("elapsed", "%.2f", o.TimeSinceStartMS(tv) / 1000.0); ./output.cc: o.TimeSinceStartMS(tv) / 1000.0); ./output.cc: o.TimeSinceStartMS(&tv) / 1000.0); ./output.cc: o.TimeSinceStartMS(&tv) / 1000.0); ./tcpip.cc: o.TimeSinceStartMS(&tv) / 1000.0, arpdesc); ./tcpip.cc: o.TimeSinceStartMS(&tv) / 1000.0, nmap_format_ippacket(packet, len)); ./tcpip.cc: o.TimeSinceStartMS(&tv) / 1000.0, Binary file ./.NmapOps.cc.swp matches ./NmapOps.h: int TimeSinceStartMS(const struct timeval *now=NULL); shows that in only one case is the return value NOT divided by 1000.0 (which casts it to a float). The one case is an assignment to the starttimems attribute of the OsScanInfo class, which is only used one place (divided by 1000.0). I'm attaching a patch that adds a function, NmapOps::TimeSinceStartS, which returns a float. It does this using a new macro, TIMEVAL_FSEC_SUBTRACT, that results in a floating-point difference in seconds, which is the most common case. After converting all the calls to use this function, I can no longer find any calls to TimeSinceStartMS, but I left it in anyway. I tested this patch with a -A -T5 -vv -dd scan of my /24 subnet, and saw no issues. There are still probably many possible overflows like this, especially given all the uses of TIMEVAL_SUBTRACT, which multiplies the difference in seconds by 1 000 000 to get microseconds. An audit of these might be in order, but I don't have the time to do it myself. Dan On Fri, Mar 25, 2011 at 7:06 AM, Daniel Miller <bonsaiviking () gmail com> wrote:
Without looking at the code, it appears to be an integer overflow with a counter keeping track of milliseconds. 25 days = 2.16e9 ms ln(2.16e9)/ln(2) = 31 So you're looking at a 32-bit signed integer. Not sure how tough it would be to change it to an unsigned, but that would buy you an extra 25 days. Or tracking the number of seconds rather than milliseconds gets you 169 years (unsigned), but the counter is probably used for something else that needs millisecond precision. Dan On Fri, Mar 25, 2011 at 2:14 AM, Mark Furst <mark.furst () clicksgroup co za> wrote:Hi there While running a nmap scan on a huge internal network for several weeks, I noticed that the elapsed time changed into negative time. I commenced the scan on 28 February 2011. The nmap command that I used is listed below: # Nmap 5.35DC1 scan initiated Mon Feb 28 08:34:17 2011 as: nmap -sS -vv -p- -T4 -oA targetname-full-20110228 -iL targetip.txt Today's date: Fri Mar 25 09:06:14 SAST 2011 Thus as the scan has been running for almost 4 weeks nonstop, it should display an elapsed time of over 600 hours by now. When getting the current nmap stats, I get the following output: Stats: -592:-33:-30 elapsed; 82127 hosts completed (4936 up), 64 undergoing SYN Stealth Scan System stats: Linux bt 2.6.34 #1 SMP Wed Jul 21 09:51:09 EDT 2010 i686 GNU/Linux System uptime: root@bt:~# uptime 09:09:36 up 31 days, 23:57, 3 users, load average: 0.09, 0.09, 0.03 cat /etc/issue: BackTrack 4 R2 Codename Nemesis \n \l Please let me know if you can replicate the issue and confirm whether it is a bug. rgds Mark Fürst (CISSP) Information Security Officer Clicks Group Limited È: +27 82 999 7770 Ê: +27 21 467 3940 ": www.clicksgroup.co.za +: mark.furst () clicksgroup co za This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail,please notify the author by replying to this e-mail and then deleting same.If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Clicks Group Limited, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Attachment:
floattime.diff
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Possible bug report - nmap scan elapsed time changes into negative time Mark Furst (Mar 25)
- Message not available
- Re: Possible bug report - nmap scan elapsed time changes into negative time Daniel Miller (Mar 25)
- Re: Possible bug report - nmap scan elapsed time changes into negative time David Fifield (Mar 27)
- Re: Possible bug report - nmap scan elapsed time changes into negative time Daniel Miller (Mar 27)
- Re: Possible bug report - nmap scan elapsed time changes into negative time David Fifield (Mar 28)
- Re: Possible bug report - nmap scan elapsed time changes into negative time Daniel Miller (Mar 25)
- Message not available