Lua Security Considerations...

[Grant Robinson]

We are trying to convince management to let us use Lua in an
enterprise-quality application that we will be distributing to
consumers.

We are embedding the Lua interpreter and our byte code into a C
application. Still, management is concerned about how hard it would
be for some hacker who knew we were using Lua to hook the VM and
inject Lua code into the interpreter. They are also concerned about
competitors disassembling our binary application and gaining access to
the Lua byte code that would include algorithms our competition would
benefit from.

My question is what can I tell management to alleviate their concerns?
Also, are there any tricks you can think of to make it harder for
someone to hack into (aka, disassemble, decompile, etc) our code and
take over our Lua Interpreter?

I have some ideas already (remove debug library, remove extraneous
loaders from the package.loaders table, disable, package.loadlib,
etc), but I am looking for other ideas and someone with practical
experience hacking Lua bytecode.

[Rob Kendrick]

On Wed, 11 Mar 2009 10:30:18 -0600

Post by Grant Robinson
Also, are there any tricks you can think of to make it harder for
someone to hack into (aka, disassemble, decompile, etc) our code and
take over our Lua Interpreter?

Use the same techniques to obfuscate this code as you're using to
obfuscate your native code.

B.

[Peter Cawley]

If a hacker is in a position in which he can hook the Lua VM, then
surely he could hook any other part of your application? Likewise, if
he could inject Lua code into the interpreter, surely he could also
inject x86 code straight into the application? Again, if they've
disassembled your application to find Lua bytecode, surely they could
have disassembled the application itself to assembly code and reverse
engineered the algorithms there?

[Mike Panetta]

If management is so worried about someone decompiling your application
binary to access the Lua code, why are they not worried aboyt someone doing
the same to the C code? If someone can decompile your code at all (which
they can, there is almost no way to stop someone from doing that) then there
is no point in worrying about Lua specificly, even your IP written in C is
at risk.

Mike

Post by Rob Kendrick
On Wed, 11 Mar 2009 10:30:18 -0600

Post by Grant Robinson
Also, are there any tricks you can think of to make it harder for
someone to hack into (aka, disassemble, decompile, etc) our code and
take over our Lua Interpreter?

Use the same techniques to obfuscate this code as you're using to
obfuscate your native code.
B.

[Javier Guerra]

Post by Mike Panetta
If management is so worried about someone decompiling your application
binary to access the Lua code, why are they not worried aboyt someone doing
the same to the C code?  If someone can decompile your code at all (which
they can, there is almost no way to stop someone from doing that) then there
is no point in worrying about Lua specificly, even your IP written in C is
at risk.

exactly my thoughts. Lua only adds entry points if the Lua code is
from an untrusted source. if your Lua code is linked into your
executable, a cracker would have to break that open first.

if you want a little more security, restrict the Lua environment as
much as possible, and put some checksums in the code to alert
modifications before executing.

[Rogers, Doug]

Post by Grant Robinson
Grant Robinson
My question is what can I tell management to alleviate their concerns?
Also, are there any tricks you can think of to make it
harder for someone to hack into (aka, disassemble, decompile,
etc) our code and take over our Lua Interpreter?

They are properly concerned. My advice would be to add some sort of
encryption to the byte code loader and compiler. If you're only worried
about authentication then the encryption could be limited to a hash of
the byte code stream at the end of each chunk being loaded. That would
allow post-processing of the compiled Lua byte codes.

I see a lot of other posts about "if they can get to the Lua they can
get to the C". That is not always true. In an embedded device it is
common to have some sort of console with a small language attached for
handling debugging or configuration. And it might also be common to have
loadable special-purpose pre-compiled binary chunks that are stored on
the client's host machine to be loaded when needed. While we don't do
that with our products (as yet!), we do have MIB configuration files
that act in a similar way. If we were to add the ability to run scripts
rather than just settings, we would be facing the same issues that your
management faces.

Given enough resources, it is always possible to get at the internals of
a device. But we're not talking about trying to beat NSA or anything -
just adding enough nuisance to make the breaking of the code more
trouble than its worth, in both effort and timeliness.

Doug
______________________________________________________________________________________
The information contained in this email transmission may contain proprietary and business
sensitive information. If you are not the intended recipient, you are hereby notified that
any review, dissemination, distribution or duplication of this communication is strictly
prohibited. Unauthorized interception of this e-mail is a violation of law. If you are not
the intended recipient, please contact the sender by reply email and immediately destroy all
copies of the original message.

Any technical data and/or information provided with or in this email may be subject to U.S.
export controls law. Export, diversion or disclosure contrary to U.S. law is prohibited.
Such technical data or information is not to be exported from the U.S. or given to any foreign
person in the U.S. without prior written authorization of Elbit Systems of America and the
appropriate U.S. Government agency.

[Grant Robinson]

On Wed, Mar 11, 2009 at 11:16 AM, Rogers, Doug

Post by Rogers, Doug
They are properly concerned. My advice would be to add some sort of
encryption to the byte code loader and compiler. If you're only worried
about authentication then the encryption could be limited to a hash of
the byte code stream at the end of each chunk being loaded. That would
allow post-processing of the compiled Lua byte codes.
I see a lot of other posts about "if they can get to the Lua they can
get to the C". That is not always true.

I agree. Lua bytecode contains a lot more information about the
original program than GCC code that has been stripped and compiled
without debugging symbols. For example, I just used LuaDec to get a
pretty decent re-creation of a Lua script. It was missing comments,
but other than that, it was pretty dang close.

I should add that this is not just using Lua for configuration, or for
game control, or any such thing. This is an entire application
written in mostly Lua (there are some parts written in C for speed,
but the core of the IP in this application will be in Lua, and not in
C).

[Luiz Henrique de Figueiredo]

Still, management is concerned about how hard it would be for some
hacker who knew we were using Lua to hook the VM and inject Lua code
into the interpreter.

If your app does not run Lua code provided by outside sources, then it's
pretty safe, as far as Lua is concerned. If your app does run user-provided
code, it does have to take special steps to make sure it does not mess with
your Lua environment, if you care about it. Then it's a matter of sandboxing.
But if your app runs user-provided Lua bytecode, then there are some holes
in the bytecode verifier that have been found recently. So, stick to running
user-provided Lua code in source form in a sandbox.

They are also concerned about competitors disassembling our binary
application and gaining access to the Lua byte code that would include
algorithms our competition would benefit from.

This is harder to avoid. Adobe Lightroom and The Sims don't seem worried about
this, but you can always encrypt the bytecode and decrypt it at load time.
But you're probably just inviting the hard-core hackers to break the encyption.

[Luiz Henrique de Figueiredo]

They are also concerned about competitors disassembling our binary
application and gaining access to the Lua byte code that would include
algorithms our competition would benefit from.

See these:
http://lua-users.org/lists/lua-l/2006-04/msg00576.html
http://lua-users.org/lists/lua-l/2006-04/msg00586.html

[Robert G. Jakabosky]

Post by Grant Robinson
We are embedding the Lua interpreter and our byte code into a C
application. Still, management is concerned about how hard it would
be for some hacker who knew we were using Lua to hook the VM and
inject Lua code into the interpreter. They are also concerned about
competitors disassembling our binary application and gaining access to
the Lua byte code that would include algorithms our competition would
benefit from.

You can compile the Lua bytecode to native code and static compile that into
your application using llvm-lua. This will provide some obfuscation of the
Lua bytecode, with an added plus of faster Lua code.

Checkout the latest code here:
http://code.google.com/p/llvm-lua/source/checkout

The latest SVN code (I just committed the changes) has some new features:
* Stripping Lua opcodes from the native compiled Lua functions. Previous
versions still had the opcodes for tracebacks.
* Compiling lua files into loadable shared libraries (tested on linux, should
work on other plantforms).
* Support for embedding llvm-lua into other applications. Right now the
embeddable llvm-lua library requires linking the application with the LLVM
libs. I will try to make this optional later.

I will try to do a new llvm-lua release soon, maybe this week if my other work
doesn't get in the way.