[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: future of bytecode verifier
- From: Kristofer Karlsson <kristofer.karlsson@...>
- Date: Thu, 5 Mar 2009 15:36:30 +0100
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:
local _loadstring = loadstring
function loadstring(src, name)
if src:byte(1) == 27 then
return _loadstring(src, name)
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 <firstname.lastname@example.org>
> You are suggesting that lua_load is still there but is administrativelyNo, only those apps that accept arbitrary user code. Those would use luaL_load
> 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?
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.