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

[David Fifield <david () bamsoftware com>]

On Thu, Sep 25, 2008 at 08:20:22PM -0600, Patrick Donnelly wrote:
> On Thu, Sep 25, 2008 at 7:26 PM, David Fifield <david () bamsoftware com> wrote:
> > On Thu, Sep 25, 2008 at 05:23:06PM -0600, Patrick Donnelly wrote:
> > > On Wed, Sep 24, 2008 at 2:20 PM, David Fifield <david () bamsoftware com> wrote:
> > > > You'll have to forgive me, I'm (still) pretty new to Lua. Is there a way
> > > > to signal a special error code that would mean a module is missing, but
> > > > it's an error that can be ignored? The error would be raised in the
> > > > "else" branch of the "if" in Sven's example, or it could even be raised
> > > > in an alternate compiled openssl module that didn't have any functions,
> > > > just raised the error. Then this special error could be ignored, and
> > > > normal require errors could continue to be reported.
> > >
> > > So perhaps the best route is ignoring errors in require for just
> > > certain modules, such as "openssl". In the same way we have a list of
> > > required fields in a script (e.g. "action" and "description"), we can
> > > have optional modules. High verbosity or debugging would still show
> > > the same messages as in my previous patch/commit.
> > >
> > > Does this sound like the appropriate functionality then to be implemented?
> >
> > Yes, but I don't want there to be a list of optional module names that
> > get special treatment. The special handling of openssl should be
> > apparent to anyone either reading the source of the openssl module, or
> > the source of the scripts that use it (one of those two). In other
> > words, the special handling of openssl should be done by openssl itself,
> > not by NSE. NSE shouldn't need to be modified except in a generic way.
>
> Fair enough. My problem is having this be necessary for every script.
> It would be simple enough to raise a specific (probably userdata)
> error in the openssl module (and all future optional modules) that NSE
> would catch. I thought of this earlier but dismissed it because it
> would replace the standard require error which may be undesirable.

Putting the checking code in every script is acceptable, mainly because
we would not be locked into doing it forever. We could take it out when
a more generic solution was developed. So I think of it as a good, safe
choice, that removes some of the risk of settling on a generic solution
too soon. So any solution that requires modifications to scripts is
fine.

I had thought that having the module raise the error was the best
solution. If you compile with --without-openssl, you still get an
openssl module, but one that doesn't do anything but raise an error.
This is nice because it doesn't require any changes to scripts. I still
think it's the best approach on balance, even though it will require an
up-to-date Nmap for the warnings to be hidden. (Running a new script on
an old Nmap that doesn't know about the optional module will show a
require error.) If it can be done easily, that's my preference.

> > Anyway, that is my idea, to allow scripts and libraries to raise
> > different kinds of errors, so NSE knows which to ignore and which not
> > to. Then the special logic goes in scripts or modules where it belongs.
> > Who knows, we might want to have other kinds of ignorable errors in the
> > future. For example, a script might need root privileges to send raw
> > packets, and it should fail without a warning when not run as root.
>
> This sound like a good idea. Perhaps we could implement a class of
> errors to add to the package library (simply package.errors) for this
> type of thing. As an example:
>
> package.errors = {
>   MISSING_SYSTEM_DEPENDENCY = newproxy(), -- newproxy makes a generic
> userdata (not in the manual)
>   MISSING_ROOT_PRIVILEGES = newproxy(),
>   ... -- etc
> }
>
> Each of which we can be aware of when running a script and handle
> these errors appropriately (perhaps with just a quiet warning).

Yes, now we're getting somewhere. Maybe we shouldn't use newproxy if
it's not documented, but the technique of using a userdata to represent
a unique type sounds perfect. I can't see the rest of the
implementation, so maybe you can provide a sketch of it. Where does the
error get raised and how? Is there a way to associate a different string
with each instance of an error?

The more I think about it, the more I think it would be good to display
the require errors whenever a script is requested specifically. So

nmap --script=default

would hide the SSH-hostkey error, while

nmap --script=SSH-hostkey.nse

would show it. Is there a nice way to differentiate between scripts
loaded by name (or directory) and scripts loaded implicitly through a
category? We might want to handle warnings for the two cases
differently. This isn't urgent, just something to think about.

David Fifield

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