Nmap Development mailing list archives

Re: Safe and Intrusive Category confusion


From: Kris Katterjohn <katterjohn () gmail com>
Date: Wed, 23 Sep 2009 00:27:54 -0500

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

On 09/22/2009 11:52 PM, David Fifield wrote:
On Tue, Sep 22, 2009 at 11:22:43PM -0500, Kris Katterjohn wrote:
When I was first talking about the mutually exclusive, all encompassing Safe
and Intrusive categories, they weren't supposed to be necessary categories for
scripts to be placed into.  It was more like stressing a script is safe (or
whatever), or used when a script didn't really fall into any other category.
A script wasn't supposed to require either and not strictly considered either
(although it could always fit in one or the other).

Dropping Intrusive and using "not safe" doesn't really allow for this.  Now
every script that is safe must be categorized explicitly as Safe or its would
now be implicitly categorized as "intrusive" (not safe).

While I guess this may not pose a great concern, it does say that any script
not categorized as Safe is thrust into the "category" or "not safe".  While
this was of course the way it was before, "not safe" != "intrusive" since
scripts didn't have to say one way or another.  It wasn't required.

By this I mean every script should always have fit into Safe or Intrusive, but
they didn't have to.  Now they do because "not safe" would be equivalent to
"intrusive", since this would be all encompassing.

Hmm... but after rereading this, I realize I may have been more stuck on rules
than practicality :)

I got caught up in this line of thinking too. I had a message
half-composed where I was going to claim that some scripts should be
neither safe nor intrusive, or that it somehow made sense for
ssh-hostkey.nse to be both safe and intrusive. But I couldn't think of
any reasons to back it up, and the descriptions of
http://nmap.org/book/nse-usage.html#nse-categories suggest that we have
been thinking about "not safe" and "intrusive" as the same thing.

      "Scripts which weren't designed to crash services, use large
      amounts of network bandwidth or other resources, or exploit
      security holes are categorized as safe."

      "[intrusive scripts] are scripts that cannot be classified in
      the safe category because the risks are too high that they will
      crash the target system, use up significant resources on the
      target host (such as bandwidth or CPU time), or otherwise be
      perceived as malicious by the target's system administrators."


I believe I mentioned something like this in my original recategorization post.

(Notice the difference between the capitalized and quoted safe/intrusive terms
I'm using)

However my issue (if it can so be called) is this:

CURRENT

* there are Safe scripts
* there are Intrusive scripts
* there are other script which can be placed in these categories but for
whatever reason the author didn't do it.  This is perfectly fine even though
the author could always label it as Safe or Intrusive.

PROPOSED

* there are Safe scripts
* there are Not Safe scripts

I agree (and I think originally said) that if scripts aren't Safe then they
are Intrusive and vice versa.  But this higher-level thinking can be different
than the application via the boolean script matching.

CURRENT

* "safe" matches only Safe scripts
* "intrusive" matches only Intrusive scripts
* "not safe" matches Intrusive and possibly other uncategorized scripts
* "not intrusive" matches Safe and possibly other uncategorized scripts
* "not safe and not intrusive" matches other uncategorized scripts

PROPOSED

* "safe" matches only Safe scripts
* "not safe" matches everything else

I realize I'm probably nitpicking here, but I think these are points which
should at least be considered before making a decision.

Everyone may look at how I've laid these out and be in favor dropping the
intrusive category (its simpler, etc), and that's perfectly fine.

Also: while I doubt anybody likes this idea, if we were to drop one of the
categories I think it should be Safe.  I think it's more plausible for scripts
to be required to explicitly call themselves Intrusive than Safe.  You have to
make a script "not safe".  Besides, Intrusive scripts can do no harm and Safe
scripts could accidently cause problems.  But I'm sure there are more
arguments against this than I can already foretell :)

I see this the exact opposite way--that explict labeling of safe is the
way to guard against accidentally running unsafe scripts. If "safe" is
the only category and you run --script=safe, and there's a safe script
that wasn't put in the "safe" category, the only harm is that one
potential script is not run. If "intrusive" is the only category and you
run --script="not intrusive", and there's an instrusive script that was
mistakenly not put in the "intrusive" category, then you will run an
unsafe script.


This is precisely why I won't fight for dropping Safe over Intrusive.

I guess how we differ is that I think about this like a simple process:

* When you begin writing a script it's automatically "not intrusive" since it
does nothing; therefore no explicit category should be specified.  However on
the flipside, the script must be explicitly labeled as doing nothing, and
hence be "safe".

* Then you add code to test auth credentials or grab system information or
whathaveyou, and it then becomes intrusive and should be labeled as such.
This is the same on the flipside as removing it from "safe".

But just as you said, the cost of being wrong is greater going this way (and
that's a great reason to not pick this way).  It just makes more sense to me
this way, disregarding the possibility of bad things happening with a
misplaced script.

David Fifield


Cheers,
Kris Katterjohn

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

iQIcBAEBAgAGBQJKubHZAAoJEEQxgFs5kUfuQLMQAKszZsRe/tTxCRH/LAvXFiGc
wIx6HJX522g6bkGMl3ZtO7FUXl3VDCaK5MOuPWU8e7g6f2UobLsBFcJfeGE/mPBS
0Ccdl0++5cBgf9qxc/ZRABdOF0w7bOCwGbexLYBjAfJpVSgJULYGJt0z0EATfmFb
wmZce4prdPZ4g1w7PIBwN0VNANs3zFWGCCsSSu51sRt/z89qeddH0g1JYTdgvmpW
HqhT7RQ49NUfZCFgLbxdxuR8x3+8lGIyAFMO5tixCwKhZneWqXIhOA11Aoi8yS3m
QXfMyaOpSM8GZ6jVGtawnbIM1lb8R3AS3Sh+9chqHxpVtI3/qTT46f130Hlosy5K
+IlDDasW+WD3SbKd+IsHfMOyTXNTEjMga9jCae2KDT3G5hCXQLERbTuyTh/aabF+
T873Vp2luO17DctBmJbbV9cYTH29Q9ceyKaWcdfPPhJ6/OfHQFIgiakGqWLUQMQh
21IX1qadFzIGr8Go9tgbqxlUiPz/vSlSRnXGB481F1XDqL7U3svlC5v3LtKAg+qG
lev8yfHzOZW6z6Ag7j+/43ic2sIoQk4NHkLm6IL4lYpBfEUeBIwLxTn4mncT84mE
lQDga7CQCicrDo8WrZJpou/SGzdFtx9N2cioNuUtBX0C46Gp/UrtN2XRvnq5aeBu
bvw4rzU804PtoRyVXLSu
=Jyqb
-----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: