Timeval subtraction coolest bug

[ithilgore <ithilgore.ryu.l () gmail com>]

Hello nmap-dev,
I am writing this, since I came across some bizarre behaviour with Ncrack.
The problem is that starting from today, the unix epoch seconds and microseconds
returned from gettimeofday() into a timeval struct in combination with some
multiplication, can get too large for a long variable to hold them.

Ncrack, like Nmap, uses some macros to make subtractions between timeval structs:

/* Timeval subtract in milliseconds */
#define TIMEVAL_MSEC_SUBTRACT(a,b) ((((a).tv_sec - (b).tv_sec) * 1000) +
((a).tv_usec - (b).tv_usec) / 1000)

Now the problem is that if the b timeval struct is just a struct initialized
with 0 (which can happen) then the first subtraction equals: a.tv_sec * 1000.
The fact that a long number (tv_sec and tv_usec are long numbers) is multiplied
by 1000, can get us a wrap around, if that long number is big enough (which
seems to be the case from today). Add to that the addition of the microseconds
in the second part of the equation and the chances of a wrap-around increase.
The wrap-around means that the returned long number is now a negative number.

This can cause some serious pain in many applications out there and I am
concerned that we might get some strange behaviour with Nmap too, since it uses
the exact same macros. I haven't tested that yet, though.

The solution of course, is to declare a long long variable as the returning
result of the timeval subtraction operation.

-- ithilgore

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