Re: Bytecode abuse in Lua 5.2 (-work4)

[HyperHacker <hyperhacker@...>]

On Sun, Aug 22, 2010 at 07:09, Stuart P. Bentley <stuart@testtrack4.com> wrote:
> It'd probably be a good idea to make rejecting bytecode in load() an #ifdef,
> with a prominent note in the manual / README that it should be defined in
> essentially anything that runs editable scripts and/or doesn't have its own
> bytecode verification routine.
>
> -----Original Message----- From: KHMan
> Sent: Sunday, August 22, 2010 A7:54 Newsgroups: gmane.comp.lang.lua.general
> To: Lua list
> Subject: Re: Bytecode abuse in Lua 5.2 (-work4)
>
> On 8/22/2010 7:37 PM, HyperHacker wrote:
>>
>> On Sun, Aug 22, 2010 at 05:17, KHMan wrote:
>>>
>>> On 8/22/2010 7:05 PM, Martin Guy wrote:
>>>>
>>>> [snip snip snip]
>>>> With Lua being embedded in every conceivable program, browser, photo
>>>> editor and web game, a security hole like this would be about as much
>>>> fun as the eternal security holes in flash player. A wise response
>>>> from the Lua dev community would be to reinstate the bytecode sanity
>>>> checking by default, and if removing it has significant advantages
>>>> (code size, speed) allowing it to be disabled only #ifdef
>>>> FAST_AND_FURIOUS
>>>
>>> "reinstate the bytecode sanity checking by default"?
>>>
>>> No you got it all wrong, the point is, there is currently no bulletproof
>>> bytecode checker, hence the old one has been withdrawn. It is vulnerable,
>>> as
>>> amply demonstrated. Peter has been at the forefront of this issue. A
>>> really
>>> good bytecode verifier will need some very, very serious work.
>>>
>>> It is easy to hope for simple solutions to loading outside code, but like
>>> all security problems, there are a lot of wide-ranging issues to look
>>> into.
>>
>> In any case where security is critical, shouldn't scripts not be
>> allowed to load (or generate) bytecode at all? IIRC load had a
>> parameter added to prevent it for exactly this reason. That's a much
>> saner solution than trying to prevent arbitrary code from being
>> malicious.
>
> Precisely, you whatever necessary in a sandbox, various details
> are available on the Lua wiki. Those unsure should read Peter's
> posting again. He has demonstrated many ways of breaking the
> bytecode verifier in the past.
>
> Performance is not really a big issue if one thinks practically. A
> very middling PC can load minimal-whitespace Lua source text from
> memory at a rate of at least 4MB/sec.
>
> So no loading untrusted bytecode if there is a need for trust...
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia
>

Why compile-time? Hide the real load() in a table that the script
never has access to, and provide your own load() that rejects any
string beginning with string.char(0x27). There you go.

(Obviously don't ACTUALLY use string.char(0x27) in the function, but
rather its precomputed result, lest the script simply redefine char.)

-- 
Sent from my toaster.