Re: Ncat's Lua socket abstraction - API protection, error behavior?

[Patrick Donnelly <batrick () batbytes com>]

Hi Jacek,

On Thu, Aug 29, 2013 at 12:05 PM, Jacek Wielemborek
<wielemborekj1 () gmail com> 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.
> There's many ways this could happen - I exposed three global variables
> (connections, connection_roots and socket) that could be written to,
> replaced or changed in some other ways. I asked the #lua guys from
> Freenode for solutions and 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.

One of the problems seems to be the connections[] table. Read-only
tables only slightly band-aid the problem. Looking for a bullet-proof
solution to prevent wrong access/writes is only going to end in
misery. Explicitly define in documentation what's allowed (don't
support undocumented/prohibited use) and/or move to an interface that
is more clear (in a documented sense) what is allowed, through
functions.

> I mean, David suggested that I should try to make the table read-only.
> But then, it's a table, there's setmetatable(),

see __metatable which is interpreted specially by [gs]etmetatable.

> there's rawset(), it
> wouldn't be hard to walk around this protection. Removing these
> functions would cripple the standard library. We could also move the
> variables to registry, but they're reachable there. I heard that even
> stack isn't completely inaccessible. Securing all the places would
> take loads of time and due to Lua's transparency, we still couldn't be
> sure that some strange script wouldn't mess it all up.

I think you need to be clearer with what you're trying to "secure".
Right now everything is too vague to make a recommendation.

> 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? I feel quite
> lost in where to draw the line here.

As I told you on IRC, scripting environments often take a hands-off
approach: "if you break it, you get to keep both pieces".

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