Nmap Development mailing list archives

Re: [NSE][PATCH] only show script errors in verbose mode


From: Sven Klemm <sven () c3d2 de>
Date: Wed, 24 Sep 2008 22:27:50 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Fifield wrote:
| On Wed, Sep 24, 2008 at 10:03:07AM +0200, Sven Klemm wrote:
|> |> I think this is an acceptable solution, though of course others are
|> |> welcome to share their opinion. I do think that this needs to be
|> |> documented in scripting.xml, that require errors are a special
case of
|> |> errors that are silently ignored.
|> |
|> | Hi David.  I agree that this patch looks promising.  Though I have a
|> | concern which as expressed in a post by Diman last night related to a
|> | different proposed solution.  If someone tries to run a script, and
|> | the required libraries can't be found (like bit, or shortport, or
|> | maybe a more specific one like pop3 related to their script), they
|> | probably won't notice the problem.  Ignoring errors is a bit
|> | dangerous, so I think we should tailor the ignore rule pretty
closely.
|> |
|> | Yesterday Sven checked in some code to his nmap-exp which modified
|> | SSH-hostkey like this:
|> |
|> | -portrule = shortport.port_or_service(22, "ssh")
|> | +if nmap.have_ssl() then
|> | +  require("openssl")
|> | +  portrule = shortport.port_or_service(22, "ssh")
|> | +else
|> | +  portrule = function() return false end
|> | +end
|> |
|> | I think this approach warrants some consideration since it is
|> | specifically targetted, and does not rely on special case "magic"
|> | behavior.  On the other hand, it puts more of a burden on script
|> | writers than Patrick's patch.  So I'm fine with whatever solution
|> | David decides on.  I agree that the ignore-require-errors approach
|> | needs to be documented if we use that.
|>
|> I am wondering whether we need to suppress those error messages at
|> all. Since --script-updatedb now skips scripts it cannot load the user
|> can get rid of those error messages by regenerating script.db.
|
| That's a good point. I think it's not common, though, for users to run
| --script-updatedb. The scripts.db we ship should include the openssl
| scripts.

The scripts.db shipped with nmap with openssl enabled should include
the openssl scripts. Maybe --script-updatedb could be run as part of
make install. I wondered why script.db is part of the repository since
it's generated, but having it in the repository has advantages too.

| Sven, is there a way to check if require("openssl") failed by actually
| trying it, rather than predicting it will fail with nmap.have_ssl? I
| mean, run require("openssl") and somehow catch any error. That would
| make the technique more general and it could become the recommended way
| to handle scripts which use any optional modules.

You cannot check this from Lua but a C function could be written that
does that. Patrick's recent patch does something like that internally
but this functionality could also be exposed to lua. But than every
script would have to do the checks. But adding this function is an
improvement over have_ssl? since other libraries might not have a
have_lib_foo? function or might not even be part of nmap so nmap does
not know whether they are available. And it would be a runtime check
which is also an advantage for external dependencies.

Cheers,
Sven

- --
Sven Klemm
http://cthulhu.c3d2.de/~sven/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjaosYACgkQevlgTHEIT4YFWgCfb19P4taEsYMS9Wq3lB9b+xUH
RzgAn3gy7zjaWUugBOk91zuEzMcvEIrg
=GWML
-----END PGP SIGNATURE-----

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


Current thread: