Re: future of bytecode verifier

[Kristofer Karlsson <kristofer.karlsson@...>]

How will the lack of bytecode verifier affect loadstring, loadfile, et.c.?

Basically I see two relevant use cases:
1) I load untrusted code which runs loadstring on evil bytecode that can hack my machine.
2) I load trusted code which runs loadstring on nice bytecode that performs useful things.

How are these cases handled on a Lua code level, i.e. calls to loadstring and loadfile.?
The ideal is for (2) to still work while being protected against (1), i.e. the untrusted code should not be allowed to call the loadstring which accepts bytecode, but the trusted code should.

Will it still be able to load bytecode, so we will have to hook it manually to disable it for evil code, like this:
do
local _loadstring = loadstring
function loadstring(src, name)
if src:byte(1) == 27 then
error"bytecode!"
end
return _loadstring(src, name)
end
end

Sorry for my incoherent questions, but I am feeling somewhat confused as to what the implications of this is.

On Thu, Mar 5, 2009 at 3:07 PM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:

> You are suggesting that lua_load is still there but is administratively
> deprecated and new code is encouraged to use a new function, luaL_load
> instead? So luaL_loadbuffer, luaL_loadfile and luaL_loadstring would all
> require the extra "nobinary" flag as well?

No, only those apps that accept arbitrary user code. Those would use luaL_load
if they want to avoid running user code in binary. Existing apps that run
binary code from known, safe sources, such as their installation directories,
don't have to change anything. We expect those are the majority of the apps.
But perhaps our perception of what apps are out there is wrong.