Re: [BUG] Exclusions directive not honored by NSE version detection

[Kris Katterjohn <katterjohn () gmail com>]

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

On Sun, 20 Jun 2010 12:08:48 -0700
Fyodor <fyodor () insecure org> wrote:

> On Thu, Jun 17, 2010 at 05:41:37PM -0500, Kris Katterjohn wrote:
> > I have never had a grasp on the inner workings of NSE, but couldn't
> > it just not pass the excluded ports to scripts in the version
> > category?
>
> That would work too, but I think it has disadvantages:
>
> o Makes the functionality more "mysterious" since the working is in
>   the engine and isn't reflected in the scripts.  So you have to know
>   about this implicit NSE rule, versus being able to see the behavior
> in scripts.

Indeed, this is the only possible disadvantage I saw.  However, I can
also see the use of --allports for using excluded ports as something
"mysterious" because it's a non-NSE option (not in --script-args) and
this isn't directly noted by the portrule function names being used, so
you can't just see this behavior in the script.  The documentation
noting this can also describe the implicit rule for the already special
version category.

The --allports option has been part of version detection, just like the
act of excluding ports by default.  The version script category is
described as an extension to the version detection system and so this
should just be a given.

> o Potential issues with the scripts we have which are in "version" and
>   other categories too (db2-das-info, db2-info).

This I haven't looked at.

> o Prevents non-version scripts from making use of the excluded ports
>   data.  Also prevents version scripts from overriding it (though I
>   doubt they will want to anyway).

I already noted that the functions making this data available to scripts
wouldn't have to go away, but should actually stay for whatever use a
script may have for it.  It just doesn't involve a set of new portrule
functions which only version scripts will use.

> I think the implicit approach would be better if we had a huge number
> of version scripts.  But the number of that scripts is small enough
> (and expected to remain that way) that I think it is better to put the
> behavior explicitly in the scripts rather than adding special magic
> behavior to the engine.

I didn't realize the number of version scripts was expected to stay
small.  But even so, adding extra stuff to scripts and library doesn't
seem right either way unless there is a good reason to keep it out of
the engine.

And again I don't see this as magic behavior when it's only for version
scripts which are an extension to version detection which does this by
default.  It's special, but not any more magic than what version
detection does.

So why does a script writer have to use separate portrule functions to
get this behavior when it should always be done?  --allports is the
toggle either way, so this (less simple) extra stuff is special too for
behavior which should be default.

> > Then the --allports option can be used to change this just like for
> > service detection.
>
> The --allports option should still work with Djalal's patch too.
> Note:
>
> +  // check if the allports option was used
> +  if (o.override_excludeports)
> +    return 0;

Of course: I didn't mean to imply that it wouldn't work with this
implementation.  I was just noting it while describing my idea, and
because the --allports option wasn't handled by that patch I was
actually replying about.

> Cheers,
> -F

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJMIBaiAAoJEEQxgFs5kUfuY6gP/0Ad/750ja7AfHdwq5nVsXwE
kCfzwd6U4pC30O3UxNrPjL1o3iHSvUYbeO6HduxRmGJ69ZB24ksziTxRRKe3L8cz
DxdAaVG8bEcKj0/40Wxx7QR4JQ/zz4MR99BaGxPRDF3qaLwhgIJqP4E3/vUUS78q
EN8UU6QC+CZVnip01RD+t2MfGCE4DMp726b4bvti8vCvmjPg6iGJNGCD1vmohOXK
DMicZpq28w/2gHbhRQOUaGz6WDPEicDskDfsJUxHzkU88l0DlQuWis/JlBuA0W8i
imgiVvO3Vug0cyqC5QnSa4HRcmKHzHRblkaM3sLJx0Pr6/UJMOLR2Wb5oOsPImtY
QKjfTRbEyT/Yva++Mc/9Cuwwy764exGAKiYquE+QqFI90oY5NZu6ssBH5QkpnFNU
RpsyzYcpfAKo7PkLVE5DEmzf3Uc6yiRjOHqA8clxgDACzYRoIIO7YG0/7qjRtxur
HStmDvfL3qpBkZ/egHdRsb3Phf/RjiOv/+4S69qQcUXTJkeGYDJtv8kV7QnG3Qiz
DHxn140Muy/+8v5KabDte4Nnk0448KKdiJNn+lW7FxYI/+E0blZYUGtwB4EunlBk
dBU3BdM+T+YFKhX94DXFDONIt2iiB1fLWGq4tbskg/wx/f1cg74TlXmKGEB0gXDw
MzEmBjs80AhB7vP0ok0i
=gffO
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/