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:
- Safe and Intrusive Category confusion Patrick Donnelly (Sep 18)
- Re: Safe and Intrusive Category confusion Ron (Sep 18)
- Re: Safe and Intrusive Category confusion David Fifield (Sep 22)
- Re: Safe and Intrusive Category confusion Ron (Sep 22)
- Re: Safe and Intrusive Category confusion Kris Katterjohn (Sep 22)
- Re: Safe and Intrusive Category confusion David Fifield (Sep 22)
- Re: Safe and Intrusive Category confusion Kris Katterjohn (Sep 22)
- Re: Safe and Intrusive Category confusion Fyodor (Sep 23)
- Re: Safe and Intrusive Category confusion David Fifield (Sep 27)
- Re: Safe and Intrusive Category confusion Patrick Donnelly (Sep 28)
- Re: Safe and Intrusive Category confusion Fyodor (Sep 28)
- Re: Safe and Intrusive Category confusion David Fifield (Sep 30)
