Bytecode abuse in Lua 5.2 (-work4)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bytecode abuse in Lua 5.2 (-work4)

Peter Cawley
As anyone who has tracked Lua 5.2's development will likely know, the
bytecode verifier was removed, and the responsibility shifted to the
end-developer to ensure that bytecode from untrusted sources couldn't
be loaded. To show just how important this responsibility is, I've
written up a pure Lua module for the default Lua 5.2 (-work4)
interpreter which can read and write arbitrary memory locations. The
only thing standing between this and a generic
arbitrary-code-execution exploit is DEP (hardware/OS level memory page
protection preventing where code can be executed from).

The code is available at:
http://www.corsix.org/lua/bytecode_abuse_0_1.lua
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Majic
Very informative, thanks! :o

On Sat, Aug 21, 2010 at 3:22 PM, Peter Cawley <[hidden email]> wrote:

> As anyone who has tracked Lua 5.2's development will likely know, the
> bytecode verifier was removed, and the responsibility shifted to the
> end-developer to ensure that bytecode from untrusted sources couldn't
> be loaded. To show just how important this responsibility is, I've
> written up a pure Lua module for the default Lua 5.2 (-work4)
> interpreter which can read and write arbitrary memory locations. The
> only thing standing between this and a generic
> arbitrary-code-execution exploit is DEP (hardware/OS level memory page
> protection preventing where code can be executed from).
>
> The code is available at:
> http://www.corsix.org/lua/bytecode_abuse_0_1.lua
>
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

martinwguy
Was this really worth posting to the entire list?

On 8/22/10, Majic <[hidden email]> wrote:

> Very informative, thanks! :o
>
>  On Sat, Aug 21, 2010 at 3:22 PM, Peter Cawley <[hidden email]> wrote:
>  > As anyone who has tracked Lua 5.2's development will likely know, the
>  > bytecode verifier was removed, and the responsibility shifted to the
>  > end-developer to ensure that bytecode from untrusted sources couldn't
>  > be loaded. To show just how important this responsibility is, I've
>  > written up a pure Lua module for the default Lua 5.2 (-work4)
>  > interpreter which can read and write arbitrary memory locations. The
>  > only thing standing between this and a generic
>  > arbitrary-code-execution exploit is DEP (hardware/OS level memory page
>  > protection preventing where code can be executed from).
>  >
>  > The code is available at:
>  > http://www.corsix.org/lua/bytecode_abuse_0_1.lua
>  >
>
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Rena
On Sat, Aug 21, 2010 at 21:43, Martin Guy <[hidden email]> wrote:

> Was this really worth posting to the entire list?
>
> On 8/22/10, Majic <[hidden email]> wrote:
>> Very informative, thanks! :o
>>
>>  On Sat, Aug 21, 2010 at 3:22 PM, Peter Cawley <[hidden email]> wrote:
>>  > As anyone who has tracked Lua 5.2's development will likely know, the
>>  > bytecode verifier was removed, and the responsibility shifted to the
>>  > end-developer to ensure that bytecode from untrusted sources couldn't
>>  > be loaded. To show just how important this responsibility is, I've
>>  > written up a pure Lua module for the default Lua 5.2 (-work4)
>>  > interpreter which can read and write arbitrary memory locations. The
>>  > only thing standing between this and a generic
>>  > arbitrary-code-execution exploit is DEP (hardware/OS level memory page
>>  > protection preventing where code can be executed from).
>>  >
>>  > The code is available at:
>>  > http://www.corsix.org/lua/bytecode_abuse_0_1.lua
>>  >
>>
>

Well I enjoyed it, but then I'm crazy like that. :-p

--
Sent from my toaster.
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Joshua Jensen
In reply to this post by martinwguy
  ----- Original Message -----
From: Martin Guy
Date: 8/21/2010 9:43 PM

> Was this really worth posting to the entire list?
>
> On 8/22/10, Majic<[hidden email]>  wrote:
>> Very informative, thanks! :o
>>
>>   On Sat, Aug 21, 2010 at 3:22 PM, Peter Cawley<[hidden email]>  wrote:
>>   >  As anyone who has tracked Lua 5.2's development will likely know, the
>>   >  bytecode verifier was removed, and the responsibility shifted to the
>>   >  end-developer to ensure that bytecode from untrusted sources couldn't
>>   >  be loaded. To show just how important this responsibility is, I've
>>   >  written up a pure Lua module for the default Lua 5.2 (-work4)
>>   >  interpreter which can read and write arbitrary memory locations. The
>>   >  only thing standing between this and a generic
>>   >  arbitrary-code-execution exploit is DEP (hardware/OS level memory page
>>   >  protection preventing where code can be executed from).
>>   >
>>   >  The code is available at:
>>   >  http://www.corsix.org/lua/bytecode_abuse_0_1.lua
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'm very interested in this.  The question I would ask at this point is
whether the built-in Lua 5.1 bytecode verifier could have prevented this?

Josh
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Jonathan Castello-2
On Sat, Aug 21, 2010 at 9:23 PM, Joshua Jensen
<[hidden email]> wrote:

>  ----- Original Message -----
> From: Martin Guy
> Date: 8/21/2010 9:43 PM
>>
>> Was this really worth posting to the entire list?
>>
>> On 8/22/10, Majic<[hidden email]>  wrote:
>>>
>>> Very informative, thanks! :o
>>>
>>>  On Sat, Aug 21, 2010 at 3:22 PM, Peter Cawley<[hidden email]>  wrote:
>>>  >  As anyone who has tracked Lua 5.2's development will likely know, the
>>>  >  bytecode verifier was removed, and the responsibility shifted to the
>>>  >  end-developer to ensure that bytecode from untrusted sources couldn't
>>>  >  be loaded. To show just how important this responsibility is, I've
>>>  >  written up a pure Lua module for the default Lua 5.2 (-work4)
>>>  >  interpreter which can read and write arbitrary memory locations. The
>>>  >  only thing standing between this and a generic
>>>  >  arbitrary-code-execution exploit is DEP (hardware/OS level memory
>>> page
>>>  >  protection preventing where code can be executed from).
>>>  >
>>>  >  The code is available at:
>>>  >  http://www.corsix.org/lua/bytecode_abuse_0_1.lua
>
> 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'm very interested in this.  The question I would ask at this point is
> whether the built-in Lua 5.1 bytecode verifier could have prevented this?
>
> Josh
>

I read it as in response to Majic, personally...

I don't usually read other people's code, but I couldn't resist
reading over this. It's definitely pretty cool! Looking at it, I can't
help but think of a possible inline "assembler" library for the Lua
VM. That would be pretty nifty. (Insecure too, obviously, but still
nifty.)

~Jonathan
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Joshua Jensen
  ----- Original Message -----
From: Jonathan Castello
Date: 8/21/2010 10:27 PM

> On Sat, Aug 21, 2010 at 9:23 PM, Joshua Jensen
> <[hidden email]>  wrote:
>>   ----- Original Message -----
>> From: Martin Guy
>> Date: 8/21/2010 9:43 PM
>>> Was this really worth posting to the entire list?
>>>
>>> On 8/22/10, Majic<[hidden email]>    wrote:
>>>> Very informative, thanks! :o
>>>>
>>>>   On Sat, Aug 21, 2010 at 3:22 PM, Peter Cawley<[hidden email]>    wrote:
>>>>   >    As anyone who has tracked Lua 5.2's development will likely know, the
>>>>   >    bytecode verifier was removed, and the responsibility shifted to the
>>>>   >    end-developer to ensure that bytecode from untrusted sources couldn't
>>>>   >    be loaded. To show just how important this responsibility is, I've
>>>>   >    written up a pure Lua module for the default Lua 5.2 (-work4)
>>>>   >    interpreter which can read and write arbitrary memory locations. The
>>>>   >    only thing standing between this and a generic
>>>>   >    arbitrary-code-execution exploit is DEP (hardware/OS level memory
>>>> page
>>>>   >    protection preventing where code can be executed from).
>>>>   >
>>>>   >    The code is available at:
>>>>   >    http://www.corsix.org/lua/bytecode_abuse_0_1.lua
>> 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.

Top posting... <sigh>

Josh
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

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

No, the biggest idiot is me. I double checked that I was only replying
to majic privately off list, but seem to have managed to spam the list
with something even more pointless. Oh well, let's hope that teaches
me some kind of lesson.

No, the original message is extremely valuable, instructive and
cautionary, and posting it is courageous... as well as it being a
technical tour-de-force!

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

I agree with majic. Nice work.

    M
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

KHMan
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
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Rena
On Sun, Aug 22, 2010 at 05:17, KHMan <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Peter Cawley
In reply to this post by KHMan
On Sun, Aug 22, 2010 at 12:17 PM, KHMan <[hidden email]> 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.

While that is true, there are reasons why the module (as it currently
stands) will not work in Lua 5.1:
1) Most importantly, 5.1's SETLIST instruction checks at runtime that
the specified table is actually a table. This check is very cheap, and
has to be done at runtime rather than load-time, but can only fail for
maliciously crafted bytecode (or specially crafted usage of
debug.sethook and debug.setlocal, but the dangers of these should
already be known). If this check was reinstated, then my module would
all stop working (as can be seen from my diagram, all reads/writes
depend on write_tvalue, which in turn depends on setlist_fn).
2) 5.2's auxiliary library buffer system uses userdata rather than
5.1's concatenation tower. Combined with the lowcall bytecode abuse,
this provides us with a simple way of getting a mutable block of
memory of specified size and initial contents, and also obtaining a
string representation of the "final" contents of the mutable block.
Doing something similar in 5.1 would be harder, though perhaps not
impossible.
3) 5.1's coroutine.running doesn't always return a coroutine, whereas
5.2's does. Given that my module just needs any coroutine, the call to
coroutine.running would have to be replaced with one to
coroutine.create (though only write_memory needs a coroutine to
inspect, the other functions work fine without the coroutine library).
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

KHMan
In reply to this post by Rena
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
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Stuart P. Bentley
In reply to this post by Jonathan Castello-2
>I don't usually read other people's code, but I couldn't resist
>reading over this. It's definitely pretty cool! Looking at it, I can't
>help but think of a possible inline "assembler" library for the Lua
>VM.

It wouldn't even be hard to make, just a series of string.gsub calls wrapped
by load().

Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Stuart P. Bentley
In reply to this post by KHMan
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

Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Rena
On Sun, Aug 22, 2010 at 07:09, Stuart P. Bentley <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Matthew Wild
On 22 August 2010 14:25, HyperHacker <[hidden email]> wrote:
>

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

Exactly one reason to have it compile-time, so that people don't make
the same fatal mistake you just did ;)

Escape (and the first char of binary chunks) is "\027", not 0x27.

Matthew
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Rena
On Sun, Aug 22, 2010 at 10:16, Matthew Wild <[hidden email]> wrote:

> On 22 August 2010 14:25, HyperHacker <[hidden email]> wrote:
>>
>
>> 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.)
>>
>
> Exactly one reason to have it compile-time, so that people don't make
> the same fatal mistake you just did ;)
>
> Escape (and the first char of binary chunks) is "\027", not 0x27.
>
> Matthew
>

Well, if I were actually writing such a function, I'd have tested it. :-p

--
Sent from my toaster.
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Henk Boom-2
In reply to this post by Stuart P. Bentley
On 22 August 2010 09:09, Stuart P. Bentley <[hidden email]> 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.

Maybe having load() reject bytecode and adding a debug.load() that
accepts it would communicate the right message.

    henk
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

KHMan
On 8/23/2010 9:39 AM, Henk Boom wrote:
> On 22 August 2010 09:09, Stuart P. Bentley 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.
>
> Maybe having load() reject bytecode and adding a debug.load() that
> accepts it would communicate the right message.

Let's stop treating developers as kiddies. Too much babysitting
and pretty soon some will come to depend on the babysitting. If
someone builds an app and skips sandboxing *when it is needed* and
skips disabling binary chunks *when it is needed*, then it is a
prototype of an application, not a completed application. Paying
customers should be wise to seek reimbursement or upgrades.

Assuming we are not using Lua as a language platform, can someone
name applications that allows loading of untrusted third party
binary chunks? Always curious for actual examples...

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Reply | Threaded
Open this post in threaded view
|

Re: Bytecode abuse in Lua 5.2 (-work4)

Jim Whitehead II
In reply to this post by Henk Boom-2

I actually think this makes a lot of sense. Providing and dealing with binary chunks is not something that should live outside the debug library, particularly given the change in attitude towards the debug library. It is a very open vector for attack and not incredibly obvious it exists in a stock distribution.

Sent from my Android device.

> On 22 August 2010 09:09, Stuart P. Bentley <[hidden email]> 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.
>
> Maybe having load() reject bytecode and adding a debug.load() that
> accepts it would communicate the right message.
>
> henk
12