Finalizers and Lua.org demo page

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

Re: Finalizers and Lua.org demo page

Egor Skriptunoff-2


And don't forget to deep copy metatable of file handles too, this metatable is accessible by getmetatable(io.output())

Sorry, I'm wrong, "io.output" is inaccessible due to sandboxing

Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Зайцев Михаил
In reply to this post by Egor Skriptunoff-2
Egor wrote:


> Yes, deep copy of whole _G into env is a solution.

> Don't forget to create new metatable for strings and set its
> __index field to env.string to prevent user from accessing original
> "string" library as debug.getmetatable"".__index


demo.lua with sandboxing: http://codepad.org/E87tf77T


Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Egor Skriptunoff-2

On Tue, Jul 25, 2017 at 8:37 PM, Mikhail Zajcev wrote:

> Yes, deep copy of whole _G into env is a solution.

> Don't forget to create new metatable for strings and set its
> __index field to env.string to prevent user from accessing original
> "string" library as debug.getmetatable"".__index

demo.lua with sandboxing: http://codepad.org/E87tf77T



1) I still can access one of original tables: getmetatable("")
2) _ENV._G == _ENV, it is a "first-level circular references", so _G will not be available?

Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Зайцев Михаил
Egor wrote:

> 1) I still can access one of original tables: getmetatable("")

Fixed this.

> 2) _ENV._G == _ENV, it is a "first-level circular references", so _G will not be available?

Manually added env._G (which is == env)

http://codepad.org/6OIg8kqK


Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Egor Skriptunoff-2
On Wed, Jul 26, 2017 at 8:08 PM, Mikhail Zajcev <[hidden email]> wrote:
Egor wrote:

> 1) I still can access one of original tables: getmetatable("")

Fixed this.

> 2) _ENV._G == _ENV, it is a "first-level circular references", so _G will not be available?

Manually added env._G (which is == env)

http://codepad.org/6OIg8kqK



I still can access original _G with this trick:

local original_G = load("return _G")()

You should redefine "load()" somehow to hide original _G from untrusted code
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Luiz Henrique de Figueiredo
> You should redefine "load()" somehow to hide original _G from untrusted code

I may be missing something here: the demo script does not need to run
user code in a complete sandbox because it does not need to protect
itself against arbitrary changes to the global environment. It does
need to save the global functions that it uses after the user program
ends and I'm grateful for the people in this thread have who pointed
that out. It also does need to prevent the user program from accessing,
hogging or getting sensitive information from the host system. But it
does not need a complicated sandbox.

Anyway, it's a good thing that the demo script is getting several eyes
looking at it.

Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Зайцев Михаил


22:21, 26 июля 2017 г., Luiz Henrique de Figueiredo <[hidden email]>:

I may be missing something here: the demo script does not need to run
user code in a complete sandbox because it does not need to protect
itself against arbitrary changes to the global environment. It does
need to save the global functions that it uses after the user program
ends and I'm grateful for the people in this thread have who pointed
that out. It also does need to prevent the user program from accessing,
hogging or getting sensitive information from the host system. But it
does not need a complicated sandbox.

Anyway, it's a good thing that the demo script is getting several eyes
looking at it.

Original issue was that messages, printed by __gc metamethod of user tables, were not displayed to user. Sandbox is an attempt to solve this issue.

For protection of functions, used by demo.lua itself, locals are just  enough.
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Зайцев Михаил
In reply to this post by Egor Skriptunoff-2
"Lua does not check the consistency of binary chunks. Maliciously crafted binary chunks can crash the interpreter."
(https://www.lua.org/manual/5.3/manual.html#pdf-load)

I think, load() should not be available to user. Potentially it is as dangerous as os.execute().

Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Soni "They/Them" L.


On 2017-07-27 02:50 AM, Mikhail Zaycev wrote:
> "Lua does not check the consistency of binary chunks. Maliciously crafted binary chunks can crash the interpreter."
> (https://www.lua.org/manual/5.3/manual.html#pdf-load)
>
> I think, load() should not be available to user. Potentially it is as dangerous as os.execute().
>

HMAC on string.dump(), verify HMAC on load().

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Coda Highland
On Thu, Jul 27, 2017 at 10:27 AM, Soni L. <[hidden email]> wrote:

>
>
> On 2017-07-27 02:50 AM, Mikhail Zaycev wrote:
>>
>> "Lua does not check the consistency of binary chunks. Maliciously crafted
>> binary chunks can crash the interpreter."
>> (https://www.lua.org/manual/5.3/manual.html#pdf-load)
>>
>> I think, load() should not be available to user. Potentially it is as
>> dangerous as os.execute().
>>
>
> HMAC on string.dump(), verify HMAC on load().
>
> --
> Disclaimer: these emails may be made public at any given time, with or
> without reason. If you don't agree with this, DO NOT REPLY.
>
>

Wrap `load()` in a function that rejects binary chunks.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Soni "They/Them" L.


On 2017-07-27 12:46 PM, Coda Highland wrote:

> On Thu, Jul 27, 2017 at 10:27 AM, Soni L. <[hidden email]> wrote:
>>
>> On 2017-07-27 02:50 AM, Mikhail Zaycev wrote:
>>> "Lua does not check the consistency of binary chunks. Maliciously crafted
>>> binary chunks can crash the interpreter."
>>> (https://www.lua.org/manual/5.3/manual.html#pdf-load)
>>>
>>> I think, load() should not be available to user. Potentially it is as
>>> dangerous as os.execute().
>>>
>> HMAC on string.dump(), verify HMAC on load().
>>
>> --
>> Disclaimer: these emails may be made public at any given time, with or
>> without reason. If you don't agree with this, DO NOT REPLY.
>>
>>
> Wrap `load()` in a function that rejects binary chunks.
>
> /s/ Adam
>

Faster load times for multi-megabyte blocks of code.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Coda Highland
On Thu, Jul 27, 2017 at 10:53 AM, Soni L. <[hidden email]> wrote:

>
>
> On 2017-07-27 12:46 PM, Coda Highland wrote:
>>
>> On Thu, Jul 27, 2017 at 10:27 AM, Soni L. <[hidden email]> wrote:
>>>
>>>
>>> On 2017-07-27 02:50 AM, Mikhail Zaycev wrote:
>>>>
>>>> "Lua does not check the consistency of binary chunks. Maliciously
>>>> crafted
>>>> binary chunks can crash the interpreter."
>>>> (https://www.lua.org/manual/5.3/manual.html#pdf-load)
>>>>
>>>> I think, load() should not be available to user. Potentially it is as
>>>> dangerous as os.execute().
>>>>
>>> HMAC on string.dump(), verify HMAC on load().
>>>
>>> --
>>> Disclaimer: these emails may be made public at any given time, with or
>>> without reason. If you don't agree with this, DO NOT REPLY.
>>>
>>>
>> Wrap `load()` in a function that rejects binary chunks.
>>
>> /s/ Adam
>>
>
> Faster load times for multi-megabyte blocks of code.
>
> --
> Disclaimer: these emails may be made public at any given time, with or
> without reason. If you don't agree with this, DO NOT REPLY.
>
>

This is a demo page that we're trying to keep from misbehaving, not a
production system that needs optimized.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Jay Carlson
On Jul 27, 2017, at 11:54 AM, Coda Highland <[hidden email]> wrote:
>
> This is a demo page that we're trying to keep from misbehaving, not a
> production system that needs optimized.

We can always play code golf.

Jay

Reply | Threaded
Open this post in threaded view
|

Re: Finalizers and Lua.org demo page

Sean Conner
In reply to this post by Coda Highland
It was thus said that the Great Coda Highland once stated:
> >
> > On 2017-07-27 02:50 AM, Mikhail Zaycev wrote:
> >>
> >> I think, load() should not be available to user. Potentially it is as
> >> dangerous as os.execute().
>  
> Wrap `load()` in a function that rejects binary chunks.

  Lua 5.3 can block binary chunks as an option.

  -spc

12