Re: [NSE] SSL support

[Patrik Karlsson <patrik () cqure net>]

On Sun, Aug 5, 2012 at 11:20 AM, Patrick Donnelly <batrick () batbytes com>wrote:

> 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

Thanks. In regards to afp.lua, if we wan't some functionality in the
library to work, which is the case for afp.lua, but catch the missing
openssl requirement in login, wouldn't we need to take the pcall approach
in this case?

//Patrik

-- 
Patrik Karlsson
http://www.cqure.net
http://twitter.com/nevdull77
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/