Re: Script suggestions, take #3

[Patrick Donnelly <batrick () batbytes com>]

On Tue, Feb 7, 2012 at 3:40 AM, Martin Holst Swende <martin () swende se> wrote:
> On 02/07/2012 06:17 AM, Patrick Donnelly wrote:
> > General comments:
> >
> > I'd rather see "suggest" scripts be a special case of a regular
> > "Script" (the class in the nse_main.lua). In that case, scripts would
> > "run" normally but the action function would be replaced with a
> > function that returns tailored output specific to the script-suggest
> > feature. Then, the majority of the engine remains unaffected and the
> > tailored script output would simply be "script-suggest: yadda yadda".
> I made an attempt at that early in the development. One thing that
> didn't quite work out
> with that approach was that the output becomes a bit haphazard:
> 80/tcp open  http
> |_http-enum: suggested {default, ...}
> |_http-title: Go ahead and ScanMe!
> |_http-foo : suggested {foo, bar}
>
> The desired (and current) effect is that all suggestions are gathered
> under a common
> heading. I don't mind changing the underlying implementation to use
> another mechanisms such
> as the one you are proposing, but I want to keep the way it is presented.
> Do you have any suggestion as to how that can be done?

I have at least two ideas for solving it:

(a) Alphabetizing the script results (this is probably a good idea in
any case). You can use some magic character like "!" or parenthesis to
prefix "script-suggest" so that it is always at the beginning of the
script output. If you prefer it at the end, there's always the curly
brackets:

batrick@batbytes ~$ lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> t = {"script-suggest:", "html-title"}; table.sort(t); for i, v in ipairs(t) do print(i, v) end
1       html-title
2       script-suggest:
> t = {"(script-suggest):", "html-title"}; table.sort(t); for i, v in ipairs(t) do print(i, v) end
1       (script-suggest):
2       html-title
> t = {"{script-suggest}:", "html-title"}; table.sort(t); for i, v in ipairs(t) do print(i, v) end
1       html-title
2       {script-suggest}:

The other (b) option is to make script output an actual class (where a
returned string is passed by the engine to a script output constructor
for backwards compatibility) and scripts can return specialized
output. For example, better error reporting, vulnerability warnings
(with some special and consistent terms for easy grepping, script
suggestions, etc. This also lends itself to consistent output
formatting. There's probably a few other benefits I've since
forgotten... I've sat on this idea for a while but no one has really
thought it useful enough to implement.

> > I also think that parsing the two sets of rules could be done
> > simultaneously. You could add a prefix [1] which specifies a suggest
> > flag similar to the force flag. The script-suggest rule set would
> > presumably always follow the rule set specified in --script. So
> > scripts which match --script-suggest are only loaded if they didn't
> > match a rule in --script.
> >
> > That should eliminate a lot of the redundant code...
> >
> > [1] http://seclists.org/nmap-dev/2011/q4/467
> I'm not sure I understand. Do you propose that the command-line syntax
> is changed, or only the implementation?
> I think you mean the former.

Initially when I thought of it, I meant the latter. Although, now that
we have gone down the rabbit hole [1], I think it may be worth it to
just add another user usable prefix and throw out --script-suggest.

This goes beyond changing the command-line syntax though. I noticed
when looking through your implementation that it was really no
different, conceptually, from the script-force feature in terms of
interpreting the rules. How you interpret the prefix changes how you
load the script, in both cases.

> Below are some usecases. Let's say we use the $-char for the
> suggestions, I'll outline possible syntaxes:
>
> #Typical scan with defaults, but show me what more I can do:
> Current #1: nmap target <ports> -sV -sC -sCS
> Current #2: nmap target <ports> -sV --script default --script-suggest all

I assume Current #1 and #2 are supposed to be equivalent.

> Flagmode  : nmap target <ports> -sV --script default,$all

Yes, this is what I would expect.

> From a user syntax PoV, I would prefer keeping them separate. The -sCS
> or e.g. --script-suggest <rule> can always
> be appended to any scan syntax very easily. I also suspect that a
> suggest-flag is even more difficult for a user to
> understand and use than the force-flag. I can go either way depending on
> what people think.

I don't really agree. I think the prefix is about as accessible and
probably more visible. The user will look at the --script
documentation and see suggestions are available by prepending a prefix
to a rule.

[1] http://seclists.org/nmap-dev/2011/q4/426 [Specifically:

"o --script is used for choosing which scripts may run. I'm concerned
that the purpose will become convoluted because not only is the user
now choosing which scripts are allowed to run, the user is also
choosing which scripts *will* run. I feel like changing the meaning of
--script will only explode with the addition of other useful features
into something terribly difficult to manage and, most importantly,
difficult to explain to users."

]

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