lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

Peter Cawley wrote:

On 24/03/2008, Daniel Stephens <daniel@danielstephens.com> wrote:

 if you trust your environment/users enough to leave binary loadstring
 available, then you also implictly trust them not to feed you invalid
 bytecode.

As loadstring and load are part of the standard core library, almost
every usage of Lua will leave them available to the user.
The one major usage I'm familiar with where lua is exposed to 'unwashed masses' from code that would otherwise expect to be robust is the use by Blizzard in World of Warcraft, in which load has been removed from the environment, and loadstring altered to reject bytecode (only lua-as-source is supported).
As with any execution environment, great thought SHOULD be given to whether or not external code (in any form, but especially binary form) should be injectable once the environment is running. 
On 24/03/2008, Daniel Stephens <daniel@danielstephens.com> wrote:

 You could of course add your own verifier that scans the
 bytecode to ensure that it's well-formed, but that kind of overhead
 feels like it may be a deliberate omission, rather than a bug.

The function luaG_checkcode (ldebug.c) is called when binary chunks
are loaded, and does just that - it checks that bytecode is
well-formed that spits out "bad code in precompiled chunk" errors for
bytecode that does things it shouldn't. However, this is one case
where said function isn't quite sufficient. Many other things that I
tried were caught by this function, but this was not.
Ah, I hadn't chased the rabbit quite that far down the hole (and was thrown of the scent by the code being in ldebug.c), I'm revising my earlier opinion - this does sound like an oversight in the verification step! 

Daniel.