Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Script force
From: Fyodor <fyodor () insecure org>
Date: Wed, 30 Nov 2011 16:11:27 -0800

On Wed, Nov 30, 2011 at 02:25:44PM +0100, Martin Holst Swende wrote:
On 11/30/2011 12:11 AM, David Fifield wrote:

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).

Yeah, the're operators are pretty powerful.

Another interesting usecase : "not +default" ==>? hopefully same as "not
default"

That sounds right to me too.

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.

That would probably be fine.  Also consider what should happen in the
reverse case "+http-* or http-title".  But I don't think we have to
put a lot of work into making these strange cases work a certain way.
I think the key is that they either work in a reasonably
predictable/justifiable way or give an error message.

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.

Personally, I wouldnt spend much time/code implementing this.  After
all, the user can easily enough just do "+default or +vuln" and that
is even shorter in this case because you don't need parens.  But it
would be great if we gave a better error message.  It would be nice if
it at least said that the --script argument was invalid and maybe
print the argument used.

Well, just for completeness, it would be nice to support as much as
possible that makes sense.

Yeah, I can see some boolean cases that are legitimately useful.  So
if they can be easily implemented and don't cause too many bad corner
cases, I think it would be a plus.  But if banning '+' and booleans is
much easier, that's fine too.

Cheers,
-F
_______________________________________________
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 ]