Re: Script force

[Martin Holst Swende <martin () swende se>]

On 11/30/2011 12:11 AM, David Fifield wrote:
> On Sat, Nov 19, 2011 at 08:22:11PM +0100, Martin Holst Swende wrote:
> > Thanks for the feedback! I had missed the categories after all, patched
> > that now. I also added a printout so it is obvious why a script is or
> > isn't executed :
> >
> > martin@linovox:~/tools/nmap$ ./nmap localhost -p1000 --script +intrusive -d
> >
> > Starting Nmap 5.61TEST3 ( http://nmap.org ) at 2011-11-19 20:13 CET
> > [...]
> > NSE: Script Pre-scanning.
> > NSE: Starting runlevel 1 (of 3) scan.
> > NSE: broadcast-avahi-dos set for execution: portrule true, force true
> > NSE: Starting broadcast-avahi-dos.
> > NSE: dns-brute set for execution: portrule false, force true
> > NSE: Starting dns-brute.
> >
> > I also changed it to use the '+'-sign, which Fyodor suggested, since it
> > has good connotations (typically what is used in a search engine to
> > specify "I want exactly this, nothing else").
> I've tested the patch and found it to do what it's supposed to when
> listing script names by themselves. I also found some funny interaction
> with the "and", "or", and "not" operators. Specifically, these operators
> always change force to false, because they do not see the second return
> value of the m function. But additionally, it's not clear what the
> correct interaction even is.
>
> Here are some test cases I tried:
>
> script name                   dport   runs?
> http-title                    -p22            no
> +http-title                   -p22    yes
> http-title,http-title         -p22            no
> http-title,+http-title                -p22            no
> +http-title,http-title                -p22            no
> +http-title,+http-title               -p22    yes
> http-title or http-title      -p22            no
> http-title or +http-title     -p22            no
> +http-title or http-title     -p22            no
> +http-title or +http-title    -p22            no
I didn't know the syntax above was even possible, I thought boolean
operators only applied to categories (or wildcards), not filenames: safe
and (discovery or default).
Another interesting usecase : "not +default" ==>? hopefully same as "not
default"

> Also, even supposing that the "or" would retain the force value, what
> should happen in cases like this?
>       http-title or +http-*
Ideally, it should load http-title normally, then load the rest of the
http-*-scripts with force flag set, but it should not load http-title
again, since that is
already loaded.
As I see it, the "force" is a modifier to ignore portrule. Loading
http-title will cause http-title not to be loaded again, even if the
second instance is ignore-portrule-modified.

> Should http-title be forced in this case? It seems like it would not be,
> because "or" will short-circuit before reading "+http-*".
>
> I also tried
>       +(default or vuln)
> I didn't really expect it to work. This was the output:
>       NSE: failed to initialize the script engine:
>       [string "rule"]:1: attempt to call a boolean value
The syntax +(default or vuln) would be nice to support, but I don't know
how much work it would be. I'll look into it.
> I'm starting to think that it shouldn't be allowed to mix + with boolean
> operators. In other words, only allow one script name or category name
> between commas when a + is present. Otherwise show an error message.
> Does this sound possible to implement? Do you have any other ideas?
Well, just for completeness, it would be nice to support as much as
possible that makes sense. I'm not sure what  you
are suggesting, could you provide an example of such "illegal" input?

In practice, I don't think this will cause any great problems.
/Martin

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

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