Re: nmap says “variable 'keys' is not declared” trying to run ssl-ccs-injection.nse

[Daniel Miller <bonsaiviking () gmail com>]

On Tue, Feb 24, 2015 at 12:02 PM, David Kozinn, K2DBK <dkozinn () gmail com>
wrote:

> ​I'm attempting to run ssl-ccs-injection.nse using nmap 6.47 from a
> Windows 7 machine. I get the following error when trying to run:
>
> ​NSE: ssl-ccs-injection against example.com (10.10.10.10:443) threw an
> error!
> C:\Program Files (x86)\Nmap/scripts\ssl-ccs-injection.nse:123: variable
> 'keys' is not declared
> stack traceback:
> [C]: in function 'error'
> C:\Program Files (x86)\Nmap/nselib/strict.lua:80: in function '__index'
> C:\Program Files (x86)\Nmap/scripts\ssl-ccs-injection.nse:123: in function
> 'test_ccs_injection'
> C:\Program Files (x86)\Nmap/scripts\ssl-ccs-injection.nse:269: in function
> <C:\Program Files (x86)\Nmap/scripts\ssl-ccs-injection.nse:245>
> (...tail calls...)
>
> A couple of things I'll mention are that I've completely uninstalled and
> re-installed nmap under Windows (using the version with Zenmap, though
> running the command from the command-line produces the same error); I did
> have to download test_ccs_injection.nse from nmap.org, and also tls.lua.
>
> The command line I'm using is:
> nmap -p 443 -d --script ssl-ccs-injection.nse --script-args vulns.showall
> example.com
>
> Any suggestions?

David,

The versions of our NSE scripts that are linked form the NSEDoc Reference
Portal [1] are the most recent bleeding-edge scripts and libraries from our
development Subversion repository. In many cases, these work just fine with
the last released version of Nmap, but sometimes we introduce
incompatibilities. Here are just a few off the top of my head since 6.47:

1. The keys() functions from several different scripts were combined into
stdnse.keys().
2. The print_debug() function was deprecated in favor of the stdnse.debug()
family of functions. This affects nearly every script.
3. OpenSSL's certificate parsing code was exposed to NSE and made use of in
ssl-enum-ciphers. This change requires a recompile from source.

The quick answer to your question is to use the copy of stdnse.lua that is
linked from the NSEDoc portal to replace the one in your release. This
*should* work fine. An alternative would be to compile from source
yourself, which is much easier on Linux or other UNIX-like operating
systems than on Windows at the moment.

To the list at large:

This issue is one that I would like to see fixed in a larger context. We
link publicly to our development-version scripts, but in many cases
(Windows in particular), users are not easily able to run the development
version of Nmap. I see a few possibilities, and I'd like to solicit your
opinions:

1. We can work on developing an automated build capability for the binary
packages we distribute, and offer those for download as a "nightly
snapshot." This would be a good thing in terms of stability, since breakage
would be more evident sooner, and users on multiple platforms could more
easily test without an explicit beta release. But it would also mean more
bandwidth usage and the costs involved in running multiple build platforms
for hours every day.

2. We can split the Nmap development tree to have a "stable" and a
"development" branch. The NSEDoc portal would link to the stable branch,
and we could still backport fixes and new, hot scripts from the development
branch as needed. This would mean extra work, though, and it's likely that
the stable branch would just stagnate until a release.

3. On a very related note, we could resurrect the nmap-update project as a
distribution platform for non-recompile changes to NSE scripts and
libraries and Nmap datafiles. This involves pretty much all the same work
as the last suggestion, but with a more explicit responsibility to keep
both branches updated.

I'm sure there are other options. I've made efforts in the past to ensure
that newly popular scripts (like ssl-poodle, ssl-heartbleed, etc.) are
backwards compatible with older releases, but this is tedious and clutters
up the scripts with hacks and FIXMEs.

Dan



[1]  http://nmap.org/nsedoc/

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/