Re: parsing of script-args is broken

[Patrick Donnelly <batrick () batbytes com>]

Hi Jah,

On Sun, Apr 26, 2009 at 5:20 PM, jah <jah () zadkiel plus com> wrote:
> Greetings,
>
> I haven't been able to pay as much attention lately as I would have
> liked, so apologies if this has in fact been addressed despite my
> efforts to find any mention of the problem.
>
> --script-args vhost=domain.co.uk is, I believe a perfectly legitimate
> argument for a script.  The intention is that the script can access the
> string assigned to vhost in the nmap.registry.args table.
>
> However, run this argument through loadstring() to check that the
> arguments are valid lua and to return a lua table like so:
>
> loadstring( 'return {vhost=domain.co.uk}' ) and what you would get back
> is: attempt to index global 'domain' (a nil value)
>
> instead of seeing the string "domain.co.uk" loadstring would see a lua
> value named "domain" and try to index the value with a lua value named "co".
>
> To prevent this in nse_main.lua, the script arguments string is passed
> through gsub() to place double-quotes around portions of it so that
> loadfile will instead interpret those portions as strings instead of
> global variables.  Trouble is, the pattern looks for "=([%w_]+)" which
> matches alphanumeric characters and the underscore and replaces them
> with "=\"%1\"".  So my vhost argument becomes vhost="domain".co.uk
> which, when passed to loadstring() as
> 'return {vhost="domain".co.uk}'
>  results in the error:  : '}' expected near '.'
>
> Hopefully it's clear that "=([%w_]+)" is insufficient to deal with all
> possible script arguments which, as I understand it, could be one or
> more name=value pairs where the value may be a string or a table [1].
> Either this method has to be made much more robust, or that replacement
> should be removed entirely and force users to ensure that, when
> providing script-args, each literal string in a name=value pair is quoted:
>
> --script-args " vhost='domain.co.uk' "
> --script-args " vhost={'domain.co.uk','domain.com'} "
>
> as long as the arguments are valid lua and the strings are quoted, then
> loadstring() will not error.
>
> I've made an attempt at improving the "stringification" of the string
> passed to loadstring() with the aim of allowing both the above examples
> and those in [1].  The attached patch:
> replaces any commas found within quoted (on windows: a single quote
> only) string literals in the script-args with the string "Ncomma".
> splits the resultant string, comma delimited
> quotes any trimmed, unquoted value if that value is not the key to
> another value (=> foo={bar="foobar"} )
> joins the resultant table and replaces any "Ncomma"s with their original
> comma.
>
> So, on windows, supplying --script-args:
> smbuser=admin,smbpass='P455,0rd',whois={whodb=nofollow+ripe},vhost={domain.co.uk,domain.com}
> the following will be passed to loadstring() :
> smbuser="admin",smbpass='P455,0rd',whois={whodb="nofollow+ripe"},vhost={"domain.co.uk","domain.com"}
>
> which I hope covers at least as many uses as --script-args currently gets.
>
> jah
>
> [1] - http://nmap.org/book/nse-usage.html#nse-args

This problem is now fixed as of r13435. As noted elsewhere in this
thread, here is a list of the new definitive rules:

--script-args <string>

<string> may contain a sequence of key=value pairs and array entries
separated by commas. All whitespace except where noted below is
ignored.

A key, value, or array value may be a sequence of characters except
'{', '}', ',', '=', and all space characters. You may overcome this
restriction by using quotes (single or double) to allow all characters
within the quotation marks. You may also use the quote delimiter
inside the sequence so long as it is escaped by a backslash.

A value for a key/value pair or an array value is allowed to be
a nested table delimited by '{' and '}'.

Cheers!

-- 
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin

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