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

[Jacek Wielemborek <wielemborekj1 () gmail com>]

Hi,

During my last meeting with David, one of the main topics of the talk
was the error behavior of Ncat's new Lua socket abstraction. While we
agreed in many cases, there's one problem that wasn't solved yet.

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.

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

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.

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