[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: 'module' called from a binary module loader
- From: "Jerome Vuarand" <jerome.vuarand@...>
- Date: Fri, 17 Oct 2008 17:18:53 +0200
Hi,
I just upgraded one of my projects using Lua from 5.1.3 to 5.1.4. Some
of my binary modules stopped working because they are calling the
'module' function in their loader. This is due to a bugfix titled
"module may change the environment of a C function." on the Lua bugs
page [1].
I'm writing my modules that way to increase consistency between my Lua
and binary modules (or in other words reduce redundancy between
'module' and luaL_register), and to eventually be able to replace the
'module' function at runtime (without recompilation) by one specific
to my application. But I'd still like my modules to work with the
default 'module' function. However I understand that the previous
implementation poses a security problem.
I didn't find a perfect solution. Here are some acceptable solutions imho.
Problem: Allow binary module loaders to call the 'module' function to
initialize the module, while preventing any other C function to call
it, especially when those C functions (for example 'pcall') are passed
user-provided callbacks (which may be 'module' itself).
1. Tag binary module loaders, and allow 'module' to be called by such
tagged C functions. The tag would be applied by the searchers that
load C modules (it could be removed as soon as the loader returns).
The tagging method could be for example putting the C function in a
special weak table in the registry (registry.module_loaders).
2. Allow 'module' to be called by a C function when it is passed an
additionnal value that could only be created by C code. For example a
light userdata, with the value 0, NULL or another special value, would
have to be passed as module second argument. Untrusted Lua code
shouldn't be able to create such a value, but it may be possible that
some binary modules return such a userdata, which then be used to
exploit the system. Another safer possibility is to pass the registry
table to module, or a special value put in the registry at a known
index.
Please comment on the problem and the proposed solutions. Other
solutions to the problem are welcome too. I'll gladly write an
implementation patch against the current Lua codebase for any solution
that may receives some sort of approval.
Jérôme, aka Doub.
[1] http://www.lua.org/bugs.html