Re: script category selection bug - was: Script force

[Djalal Harouni <tixxdz () opendz org>]

On Sat, Dec 03, 2011 at 10:41:47PM +0100, Martin Holst Swende wrote:
> On 12/01/2011 11:47 PM, Djalal Harouni wrote:
> > On Tue, Nov 29, 2011 at 03:11:32PM -0800, David Fifield wrote:
> > > 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
> > We can also support this but it will need more regexp checks, perhaps we
> > should just let users specify "+default or +vuln" as suggested by
> > Fyodor.
> >
> > I'll try to have a look at this error.
>
> Currently, there is an error since the globalized_rule is created on the
> "+(default or vuln)" string instead of "(default or vuln)".
> If the force-check/removal is moved up, it does not crash (but has no
> effect - force is not used)
> What happens currently is that the substring in globalize becomes empty,
> since gsub will cut the input at first "(". This is the result:
>
> m("")(m("default") or m("vuln"))
Yes the substring becomes empty but this will not trigger the bug.

This bug was present before this patch, you can test it with this:
--script="foo(default and vuln)"


The bug which is a funny one (and perhaps dangerous, not sure) is
triggered when we run this compiled chunk:
m("")(m("default") or m("vuln"))

1) m("") will return a boolean (probably false).

2) m("default") or m("vuln") will run and return X results.

3) the first 'm("") == false' will be:
   false('results of (2)')


At 3) the compiled function will try to call the returned boolean value
as a function.


Hopefully you can't set boolean values and the environment is cleared,
but you can try this:
--script="\"..m..\""
...
NSE: failed to initialize the script engine:
[string "rule"]:1: attempt to concatenate global 'm' (a function value)

It seems that we can't call external or local functions (I did not test
them), but we must be sure otherwise this can affect hosted Nmap scan
services with script support and external input.

> So either we can fix it or we can add an error message if the substring
> returned by is_forced_set
> is empty...? Fixing it involves making the force-flag somehow being
> injected into the script names correctly according to boolean
> math ... something which so far cleverly has been handed over to the
> lua-engine instead.
To fix it we should just parse the globalized rule:
m("")(m("default") or m("vuln"))

If we find two m("...") functions not separated by 'and', 'or' or ','
then we raise a fatal error:
(e.g: "multiple script categories must be sperated by ',').

Of course before running that chunk.

> Regards,
> Martin
I'll fix it ASAP, thanks.

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