Re: Specially crafted binary chunks can cause Lua to crash

["Peter Cawley" <lua@...>]

I noticed that the fix I proposed doesn't check if C = 0, so it should
be more like:
if(pt->sizecode > 1) check(GET_OPCODE(pt->code[pt->sizecode-2]) !=
OP_SETLIST || GETARG_C(pt->code[pt->sizecode-2]) != 0);

Also, the code to exploit it can be reduced to a single line:
loadstring(string.dump(function()return;end):gsub(string.char(30,37,122,128),string.char(34,0,0),1))()

On 24/03/2008, Daniel Stephens <daniel@danielstephens.com> wrote:
> 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.
>
>