Re: [patch] changing lua_Number to int64_t

[Marc Balmer <marc%msys.ch@localhost>]

Am 17.11.13 22:03, schrieb Terry Moore:
>> From: Marc Balmer [mailto:marc%msys.ch@localhost]
>>
>>> It's not *much* less safe than compiling and executing a string in the
>>> kernel. The only additional attack surfaces are that you can write
> things
>>> that the compiler wouldn't write. This can (1) cause a crash at load
> time,
>>> or it can (2) cause surprising behavior later.
>>
>> The problem is that malicious bytecode in 5.1 is possible.  That is why
>> there is a guad against loading bytecode.
> 
> Malicious in what sense? Is this a type-1 problem or a type-2 problem? Or
> something else that I've not considered?

See Peter Cawleys talk he gave during LWS 2011 in Frick.

"Mitigating the danger of malicious bytecode

Peter Cawley (University of Oxford)

In Lua 5.1 and 5.2, the family of load functions permit the loading of
precompiled bytecode in addition to plain source code. We shall look at
some relevant details of the bytecode, and see how these details can be
maliciously abused to escape from a Lua sandbox (in both 5.1 and 5.2).
With the dangers presented, we shall then move to look at two ways of
mitigating them. Firstly, one can wrap the load functions as to reject
bytecode before it is loaded. Secondly, and more interestingly, one can
attempt to algorithmically decide whether a given piece of bytecode is
malicious or not. We shall look at two such algorithms for validating
bytecode: LBCV, which tries to reject as little as possible, and my
current experimental verifier, which tries to accept as little as
possible. "


http://www.lua.org/wshop11/Cawley.pdf