Nmap Development mailing list archives
Re: Weird target specifications
From: David Fifield <david () bamsoftware com>
Date: Thu, 19 Feb 2009 15:51:37 -0700
On Thu, Feb 19, 2009 at 02:07:09PM -0800, Fyodor wrote:
On Thu, Feb 19, 2009 at 11:57:38AM -0700, David Fifield wrote:Specification Interpreted as 1.2.3.-5 1.2.3.0-5 1.2.3.5- 1.2.3.5-255 001.002.003.004 1.2.3.4Test them out by running "nmap -n -sL -- <specification>". All of these, except for 001.002.003.004, are currently syntax errors in the Ncat code. Are any of these intentional, supported syntax that Ncat needs to be compatible with? The only ones I think you can make a case for are 1.2.3.-5 and 1.2.3.5-, but if those are supported then 1.2.3.- should mean 1.2.3.0-255.I agree that a case could be made for allowing - at an edge to mean "up to"/"or greater", or by itself as an octet wildcard. We already use '*' as a wildcard, but that causes problems with shell interpretation. So there is something to be said for using '-' for that instead, and then deprecating '*', unless there are problems with '-'. One possible issue is that '-' is allowed in hostnames, while '*' isn't. But that doesn't seem like a particularly hard issue to resolve (and to some degree we already have to anyway since we use '-' in ranges already). And I don't think they should be at the beginning or end of any legit DNS segment.
I think that's a good idea. I hadn't thought of '-' as a replacement for '*', though it would work that way. The only difficulty with is when the '-' is in the first octet--then it looks like an option to the command-line parser. That's why I had to put "--" in the example command line above. $ nmap -.1.1.1 > /dev/null nmap: unrecognized option `-.1.1.1'
I'm kind of neutral on the zero-padded versions like 64.13.134.052. My version of ping treats the 052 as octal, which I don't really think we should replicate. I can sort of see someone using excel or something to generate IPs and ending up with a zero padded number, but its a stretch. I don't see much benefit to allowing them, but I supposed I'm not opposed to it if there is a plausible reason (or if it makes the implementation easier).
That's interesting that it becomes octal. My guess is they're calling strtol with a base of 0, which enables extra syntax like that. To prohibit leading zeroes would require additional code; I think all it takes is checking that the current character is not '0' before parsing the int. Allowing the zeroes is a more straightforward implementation. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Weird target specifications David Fifield (Feb 19)
- Re: Weird target specifications Fyodor (Feb 19)
- Re: Weird target specifications David Fifield (Feb 19)
- Re: Weird target specifications David Fifield (Feb 20)
- Re: Weird target specifications Fyodor (Feb 20)
- Re: Weird target specifications David Fifield (Feb 23)
- Re: Weird target specifications David Fifield (Feb 19)
- Re: Weird target specifications Fyodor (Feb 19)
- Re: New syntax for Ncat --allow and --deny Fyodor (Feb 20)
- Re: New syntax for Ncat --allow and --deny David Fifield (Feb 21)