Re: Weird target specifications

[Fyodor <fyodor () insecure org>]

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'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).

Cheers,
-F

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