Re: New functions to target.lua library (NSE Leftovers - Part 1)

[David Fifield <david () bamsoftware com>]

On Tue, Aug 21, 2012 at 05:20:34PM -0400, Brendan Byrd wrote:
> On Tue, Aug 21, 2012 at 5:18 PM, Brendan Byrd <sineswiper () gmail com> wrote:
> > (This is a split of a larger patch here:
> > http://seclists.org/nmap-dev/2011/q4/558)
> >
> > This patch contains a few new functions to target library, including an exclude
> > list to prevent duplicate IPs from being added, even down to the IP level for
> > ranges.
> >
> > Some caveats:
> >
> >    1. Everything is in Lua.  This should probably be converted to pure C code,
> >    for speed and accessibility to internal data.
> >
> >    2. This library doesn't have access to NMap's main target and exclude lists,
> >    so the new "dupe list" is outside of the existing lists.  This means that a
> >    new target could still dupe one of the command-specified targets, but it
> >    won't dupe after that.  This also means that adding a target to the exclude
> >    list isn't going to remove future targets that were already added
> >    previously.  Fixing point #1 would solve all of this.
> >
> > Despite the caveats, I think this might be a good band-aid in the meantime.
>
> Yay, it would help if I included the attachment...

Thanks for this, Brendan. I like the idea, which, if I understand
correctly, is to prevent "192.168.0.123" from being scanned twice when
you do
        target.add("192.168.0.0/24")
        target.add("192.168.0.123")
Currently the target will be scanned twice because the target library
only does string comparison to check for duplicates.

This patch seems overly complex for what it does. I wasn't able to
understand it after spending a few minutes. It seems to be managing a
structure of IP ranges, then testing new specifications to see if they
overlap?

Are there scripts that are currently causing a problem with adding the
same target more than once? I admit that we currently have a bug, but I
think we can live with it unless there is a very simple solution. I'm
guessing that it's hardly ever a problem in practice.

I think writing this functionality in C is a bad idea.

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