Re: Possible bug report - nmap scan elapsed time changes into negative time

[Daniel Miller <bonsaiviking () gmail com>]

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/