RE: future of bytecode verifier

["John Hind" <john.hind@...>]

Certainly adding a "reject bytecode" parameter to loadstring/loadfile is a
good idea, should not break compatibility and could be regarded as a
"bug-fix".

However removing the existing bytecode verification is a bigger change which
breaks conceptual compatibility (since people may be relying on it) and
should probably wait for 5.2. At this point, I would argue, you are reducing
the security of existing code and this should be compensated by separation
of the bytecode and "normal" input channels to make it easier to control the
latter, even if this does break compatibility for bytecode applications.

I do agree with LHF that bytecode verification should be removed if it
cannot be made watertight and it should be the responsibility of anyone
using this feature to ensure "evil bytecode" cannot be presented for
reading. But it should be made as easy as possible to discharge that
responsibility, and non-bytecode using applications should not have to worry
about it - i.e. the channel should be closed by default.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Roberto
Ierusalimschy
Sent: 05 March 2009 15:41
To: Lua list
Subject: Re: future of bytecode verifier

> Basically I see two relevant use cases:
> 1) I load untrusted code which runs loadstring on evil bytecode that can
> hack my machine.

When you run untrusted code, you already have to constrain what functions
it can use. So the point is whether loadstring should be considered
a safe or an unsafe function. 

Our problem is a conflict between compatibility and security. If we
favor compatibility, we should keep loadstring/loadfile accepting "evil
bytecode", and those concerned with security issues should correct their
code. If we favor securiy, we could make loadstring/loadfile refuse
"evil bytecode", and those concerned with compatibility should correct
their code.

I see two points to favor compatibility. The first (and stronger) is
that the current loadstring/loadfile is already broken. We will not
break compatibility in a bug-fix release (5.1.5), so those concerned
with security will either wait for 5.2 (many months ahead) or will have
to fix their code now, anyway. The second reason is that we believe
there are much more people using loadstring/loadfile in "normal"
use (not running or being called by untrusted code) than in special
uses. (I am mostly sure this is true for loadfile; may not be true for
loadstring, though.) So, by favoring compatibility we would annoy less
users.

-- Roberto

Attachment: smime.p7s
Description: S/MIME cryptographic signature