Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: script category selection bug - was: Script force
From: Djalal Harouni <tixxdz () opendz org>
Date: Mon, 5 Dec 2011 16:38:11 +0100

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]