Nmap Development mailing list archives
Timeval subtraction coolest bug
From: ithilgore <ithilgore.ryu.l () gmail com>
Date: Thu, 16 Jul 2009 18:51:48 +0300
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
Current thread:
- Timeval subtraction coolest bug ithilgore (Jul 16)
- Re: Timeval subtraction coolest bug David Fifield (Jul 16)