Home page logo
/

nmap-dev logo 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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault