Re: [NSE] SSL support

[Patrick Donnelly <batrick () batbytes com>]

Hi Patrik,

On Sun, Aug 5, 2012 at 4:43 AM, Patrik Karlsson <patrik () cqure net> wrote:
> I noticed/fixed a few things;
> * A few libraries have "require openssl" before the silent_require call. I
> may have contributed to this by doing my fix-up runs based on the result of
> nse_check_globals. Patrick, would it be possible to get nse_check_globals to
> understand the silent_require calls and even the pcall(require("openssl"))?

It already does. What probably happened is (a) the script writer
didn't save the returned library from silent_require to a local or (b)
the library was never required and nse_check_globals patched the
script to require the library.

There's little magic to nse_check_globals. If it finds an indexed
global variable and that variable name exists in nselib/*.lua or
nselib/*.luadoc, then it detects this as an unrequired library. For
example, in http-title.nse:

-- local http = require "http"
...
function action (host, port)
  http.get(host, port, ...)
end

Will give us an unrequired library error because the http variable is
global and corresponds to a library in nselib:

Checking: scripts/http-title.nse
        Found unrequired NSE library "http" on line 38:39.

In contrast:

local http = require "http"
...
function action (host, port)
  httP.get(host, port, "/foo")
end

will just give us a bad indexed global error:

Checking: scripts/http-title.nse
        Found bad indexed global "httP" on line 38:38.

So the return value of stdnse.silent_require is stored in a local,
nse_check_globals will be happy. There's no difference between require
or stdnse.silent_require.


So, for nselib/afp.lua, it looks like this should have been:

$ svn diff nselib/afp.lua
Index: nselib/afp.lua
===================================================================
--- nselib/afp.lua      (revision 29493)
+++ nselib/afp.lua      (working copy)
@@ -114,19 +114,14 @@
 local bin = require "bin"
 local bit = require "bit"
 local nmap = require "nmap"
-local openssl = require "openssl"
 local os = require "os"
 local stdnse = require "stdnse"
 local string = require "string"
 local table = require "table"
 _ENV = stdnse.module("afp", stdnse.seeall);

-local HAVE_SSL = false
+local openssl = stdnse.silent_require "openssl"

-if pcall(require,'openssl') then
-  HAVE_SSL = true
-end
-
 -- Table of valid REQUESTs
 local REQUEST = {
        CloseSession = 0x01,
@@ -890,10 +885,6 @@
                local data_offset = 0
                local status, response

-               if not HAVE_SSL then
-                       return false, "OpenSSL not available, aborting ..."
-               end
-
                -- currently we only support AFP3.3
                if afp_version == nil or ( afp_version ~= "AFP3.3" and
afp_version ~= "AFP3.2" and afp_version ~= "AFP3.1" ) then
                        return false, "Incorrect AFP version"

Note that the pcall(require, "openssl") doesn't save the return value
of require to a local named "openssl". This would have also worked:

local status, openssl = pcall(require, "openssl")
if not status then
  HAVE_SSL = false
end

> * Some scripts requiring a library, which in turn had a silent_requires,
> returned "attempt to yield across metamethod/C-call boundary" during the
> --script-updatedb.
> I solved this by adding a silent_require for that library in those scripts.
> Not sure whether this is the best way, but I some some traces of that in a
> few scripts and it works.

This is my fault. silent_require should be throwing an error, not
yielding. Please run through these again with the updated
nse_main.lua.

> * nse_main.lua didn't seem to handle scripts having a silent_require very
> well, as the scripts would fail to load, returning nil which wasn't caught
> when attempting to sort the categories  and write it to the scripts.db. I
> think the attached patch may solve this appropriately as well.

That looks good.

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