Re: Weird target specifications

[David Fifield <david () bamsoftware com>]

On Fri, Feb 20, 2009 at 11:19:19PM -0800, Fyodor wrote:
> On Fri, Feb 20, 2009 at 09:05:26PM -0700, David Fifield wrote:
> > 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:
> >
> > 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.
>
> Sometimes we just forget to document features (particularly true of
> ancient ones such as this).  Other times (rarely) a feature is
> considered minor enough that it isn't worth documenting due to the
> increase in complexity of the documentation.  But even if that was the
> case for this sort of half-open ranges, the addition of full-open
> ranges pushes it into deserving documentation, IMHO.
>
> There are also times when we don't document a feature because it is
> deprecated and we don't really want to encourage its use.  For
> example, perhaps if we document the use of '-' as an octet wildcard,
> we don't need to bother documenting '*' for the same purpose.
> Unfortunately, neither is perfect.  '*' needs to be shell-escaped on
> many systems, while David noted that '-' causes can cause problems at
> the beginning of a specifier (Nmap thinks it is an option flag).
>
> I'm not sure which one (or both) of those we should document.  I'm
> leaning toward just documenting '-' though.  We just need to mention
> that if '-' appears as the first character in the specifier, you just
> need to prepend a zero.  Or if it is easy to modify the argument
> parsing logic, perhaps we could fix the issue there (ignore this case
> during option parsing) and so we don't have to bother users with it at
> all.

I committed a brief mention of - and not * in the target specification
documentation. I said that you need to use "0-" in the first octet. It
would be nice if the option parser could deal with it instead, perhaps
by saving unrecognized options that look like host specifications. But
the more I think about it the more difficulties I see. The hardest case
I can think of is this:
        nmap -6.1.2.3
We might like to treat that as 0-6.1.2.3, but getopt_long_only peels off
the -6 because that is a real option. The error message you get is
        nmap: unrecognized option `-.1.2.3'
The host specification seen by us would be -.1.2.3, not the same thing.

But starting with a - works fine in the argument to --exclude and in
files loaded with -iL. It's reminiscent of another little problem: you
can't use commas in ranges passed to --exclude because --exclude splits
on commas. But they work fine everywhere else.

David

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