mailing list archives
Re: Ncat's Lua socket abstraction - API protection, error behavior?
From: Patrick Donnelly <batrick () batbytes com>
Date: Sun, 1 Sep 2013 17:39:55 -0400
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
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".
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/