RE: Lua Security Considerations...

["Rogers, Doug" <Doug.Rogers@...>]

> 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.