RE: [patch] safety of Lua byte code

["Terry Moore" <tmm%mcci.com@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
> 

So we're discussing what I called a "type-2" problem, escaping the sandbox.

Really, however, if you load any code of any complexity into any VM, you are
at risk -- no matter how it the code is presented (byte code or source). If
you are loading code you don't know into a Turning-complete VM that's
running in the kernel, you are making a very strong assumption (and one that
seems, based on experience in the software industry to be unwarranted) about
the correctness of the compiler, run-time system, etc. I am not referring to
Lua in particular; the code is pretty good. I'm referring instead to the
general complexity of the VM environment. 

I personally would never run untrusted code of any kind in the kernel,
whether provided in source form or binary form, whether sandboxed or not,
unless the VM is very limited (along the lines of the BPF VM).

This isn't to say that Lua is not useful in the kernel. It is, however, to
say that I'd be very reluctant to let an adversary have carte blanche to
inject Lua code, in source or binary form, into the kernel. (This goes for
*any* language, C, Python, binary. Injecting Lua code into your kernel is
like doing an insmod -- you had better be asserting that you trust the code
*completely*. In fact, the use case of a serial protocol coded in Lua is
exactly an insmod-like application.) 

Nobody would seriously claim, I think, that one can algorithmically
determine whether a given fragment of Lua *source* code is malicious. Yes,
Lua byte codes can be malicious in additional ways, but I think worrying
about this misleads us about the nature of the problem.

If you're worrying about the safety of the compiled code in this sense, then
you should really be worrying about the safety of having the compiler in the
kernel at all.  I think that the paper you refer to is more motivated by use
cases such as running Lua in a web browser a-la Java, or in a game WoW,
where the code is injected into a VM without any real authentication.  

Best regards,
--Terry