Re: Weird target specifications

[David Fifield <david () bamsoftware com>]

On Thu, Feb 19, 2009 at 03:51:37PM -0700, David Fifield wrote:
> On Thu, Feb 19, 2009 at 02:07:09PM -0800, Fyodor wrote:
> > 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 new Ncat code recognizes a lone dash as "0-255". I modified Nmap to
work the same way. It was a one-line bug fix to make Nmap support it; it
looks like it was intended all along but a coding error kept it from
working. A pointer was being compared to zero when it should have been
dereferenced first.

Is there any reason why these half-open and full-open ranges aren't
documented? Looking at the TargetGroup.cc code, support for them was
intentional and not just an artifact of parsing.

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

I decided to leave things the way they are and allow leading zeroes.

David Fifield

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