lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sun, Aug 22, 2010 at 05:17, KHMan <keinhong@gmail.com> wrote:
> On 8/22/2010 7:05 PM, Martin Guy wrote:
>>>>>>>
>>>>>>> Very informative, thanks! :o
>>>>>>
>>>>>> Was this really worth posting to the entire list?
>>>>>
>>>>> Your comment was made because you're not interested in the subject or
>>>>> because you prefer security through obscurity?  Or for some other
>>>
>>> reason?
>>>>
>>>> I read it as in response to Majic, personally...
>>>
>>>  Now, I'm embarrassed.  I see Majic's comment now, and I can see why
>>> Martin
>>> made the comment.
>>
>> [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.
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia
>

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.

-- 
Sent from my toaster.