Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Ncat's Lua socket abstraction - API protection, error behavior?
From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 29 Aug 2013 12:25:16 -0500

On 08/29/2013 11:05 AM, Jacek Wielemborek wrote:
Since all filter scripts share the same namespace, there's a risk that
one filter layer can break another and lead to some nasty crash.
How nasty are we talking? Aborting the whole program is nasty, but doesn't hurt if you're just developing a new filter and did something wrong. As long as you get a decent error message that somewhat indicates what went wrong, I think allowing filter authors to cause crashes while developing filters is not a bad thing.
while there could be some hacks done with
userdata, tables and such, they pointed out that there might be no
point trying to create a bullet-proof API.
An API doesn't need to be bullet-proof, just idiot-resistant. If there is a clear and easy way to do what is needed, it doesn't matter so much if there's a difficult and non-obvious way to break it. Security issues would be the exception; if you're designing an API that separates privilege levels, then you have to be more strict. In the case of Ncat filters, you would want to be sure that an author cannot accidentally create a security bug. Intentional security problems are different: if the filter runs every line through os.execute(), then prevention should be a cricket bat, liberally applied.
Perhaps it would be better do define things that just shouldn't be
done (like overwriting the registry) and assume that user can't do
them by mistake, so there's no point securing them all?
This is essentially my view. Simple things like ensuring a value cannot be changed by simple assignment is all that should be necessary. If someone knows enough to mess around with metatables, then they can take responsibility for their own actions.

But even in the worst case (perhaps one of your global vars can be overwritten, borking the whole program) does it hurt anyone?It's part of learning the development environment and API that you're setting up. I'm sure I could "break" NSE by doing dumb things, but then I'm just stuck with a script that breaks for me. Nobody else will accept it, because it's broken.Unless I broke it in a clever and new way (hacked it) that introduces useful functionality---this is the potential upside of a "fragile" API.

Dan

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault