Re: Weird target specifications

[David Fifield <david () bamsoftware com>]

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.4
>
> > Test 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