Discover default package.path, package.cpath?

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

Discover default package.path, package.cpath?

Norman Ramsey
From within a Lua process that has already launched, is there a way to
discover the *default* paths, especially package.cpath?

Context: I have to treat the LUA_CPATH environment variable as if it
were controlled by an adversary, and I do not have the ability to
launch Lua with the -E option.  My choices will be either to put some
kind of wrapper around my Lua binary or to launch a separate process
to determine the default path.  Neither of these choices is ideal.

A solution for 5.1 would be perfect, but if it's doable even using a
later version, I might be able to retrofit.  

Any ideas?


Norman

Reply | Threaded
Open this post in threaded view
|

Re: Discover default package.path, package.cpath?

Sean Conner
It was thus said that the Great Norman Ramsey once stated:

> From within a Lua process that has already launched, is there a way to
> discover the *default* paths, especially package.cpath?
>
> Context: I have to treat the LUA_CPATH environment variable as if it
> were controlled by an adversary, and I do not have the ability to
> launch Lua with the -E option.  My choices will be either to put some
> kind of wrapper around my Lua binary or to launch a separate process
> to determine the default path.  Neither of these choices is ideal.
>
> A solution for 5.1 would be perfect, but if it's doable even using a
> later version, I might be able to retrofit.  

  First, what is your thread model?  Is it *just* LUA_CPATH and not
LUA_PATH?  Or LUA_INIT?  If it's just to prevent an adversary from loading a
custom version of a C-based module, all they need to do is call
package.loadlib() directly to load a C-based module.

  Second, is modifying Lua an option?  If so, you could always modify
loadlib.c:setpath() to not query LUA_CPATH (and even LUA_PATH) and to
prevent package.loadlib() from being included in the Lua state.  But there
might be more you will have to do depending upon your threat model.

  -spc (Did I just say "threat model?"  Sheesh ... )


Reply | Threaded
Open this post in threaded view
|

Re: Discover default package.path, package.cpath?

Norman Ramsey
 > It was thus said that the Great Norman Ramsey once stated:
 > > From within a Lua process that has already launched, is there a way to
 > > discover the *default* paths, especially package.cpath?
 > >
 > > Context: I have to treat the LUA_CPATH environment variable as if it
 > > were controlled by an adversary, and I do not have the ability to
 > > launch Lua with the -E option.  My choices will be either to put some
 > > kind of wrapper around my Lua binary or to launch a separate process
 > > to determine the default path.  Neither of these choices is ideal.
 > >
 > > A solution for 5.1 would be perfect, but if it's doable even using a
 > > later version, I might be able to retrofit.  
 >
 >   First, what is your thread model?  Is it *just* LUA_CPATH and not
 > LUA_PATH?  Or LUA_INIT?  If it's just to prevent an adversary from loading a
 > custom version of a C-based module, all they need to do is call
 > package.loadlib() directly to load a C-based module.

Oy.  I need to protect LUA_PATH as well (and LUA_PATH_5_x, and ...).
I overlooked LUA_INIT.  I need to do something like that as well.

 >   Second, is modifying Lua an option?

No.  It's running on an installation that I don't administer, and on
the whole, I think I'd rather pay an extra dynamic cost on every run,
rather than rely on all future administrators to preserve something
special.

I suppose I can simply cause my code to crash if any of the sensitive
environment variables are set.  Inconvenient, but safe.



Norman

Reply | Threaded
Open this post in threaded view
|

Re: Discover default package.path, package.cpath?

Sean Conner
It was thus said that the Great Norman Ramsey once stated:

>  > It was thus said that the Great Norman Ramsey once stated:
>  > > From within a Lua process that has already launched, is there a way to
>  > > discover the *default* paths, especially package.cpath?
>  > >
>  > > Context: I have to treat the LUA_CPATH environment variable as if it
>  > > were controlled by an adversary, and I do not have the ability to
>  > > launch Lua with the -E option.  My choices will be either to put some
>  > > kind of wrapper around my Lua binary or to launch a separate process
>  > > to determine the default path.  Neither of these choices is ideal.
>  > >
>  > > A solution for 5.1 would be perfect, but if it's doable even using a
>  > > later version, I might be able to retrofit.  
>  >
>  >   First, what is your thread model?  Is it *just* LUA_CPATH and not
>  > LUA_PATH?  Or LUA_INIT?  If it's just to prevent an adversary from loading a
>  > custom version of a C-based module, all they need to do is call
>  > package.loadlib() directly to load a C-based module.
>
> Oy.  I need to protect LUA_PATH as well (and LUA_PATH_5_x, and ...).
> I overlooked LUA_INIT.  I need to do something like that as well.

  Don't forget package.loadlib().

>  >   Second, is modifying Lua an option?
>
> No.  It's running on an installation that I don't administer, and on
> the whole, I think I'd rather pay an extra dynamic cost on every run,
> rather than rely on all future administrators to preserve something
> special.

  You could always wrap the invokation of lua in a shell script that
modifies the environment (by removing $LUA_*) and then execs the actual lua
executable but I find it odd that you can't run lua with the '-E' option.
Is your threat model the actual system administrators?  Just how would an
adversary get control?

  -spc (Kind of confused here ... )

Reply | Threaded
Open this post in threaded view
|

Re: Discover default package.path, package.cpath?

nobody
In reply to this post by Norman Ramsey
On 03/01/2019 23.09, Norman Ramsey wrote:
> I suppose I can simply cause my code to crash if any of the sensitive
> environment variables are set.  Inconvenient, but safe.

LUA_INIT can re-define os.getenv to always pretend that LUA_INIT*,
LUA_*PATH* etc. are absent.  (LUA_INIT can re-define absolutely anything
and do whatever it wants… it could easily wrap debug.sethook,
debug.getinfo etc. and deliver the fantasy that you want to believe in.)

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Discover default package.path, package.cpath?

Muh Muhten
On 1/3/19, nobody <[hidden email]> wrote:
> On 03/01/2019 23.09, Norman Ramsey wrote:
>> I suppose I can simply cause my code to crash if any of the sensitive
>> environment variables are set.  Inconvenient, but safe.
>
> LUA_INIT can re-define os.getenv to always pretend that LUA_INIT*,
> LUA_*PATH* etc. are absent.  (LUA_INIT can re-define absolutely anything
> and do whatever it wants… it could easily wrap debug.sethook,
> debug.getinfo etc. and deliver the fantasy that you want to believe in.)

Your program can even be run under an interpreter that ignores it and
runs a different program entirely; LUA_INIT is arbitrary code
execution already.

What are you trying to prevent? What are you trying to protect?

Reply | Threaded
Open this post in threaded view
|

Re: Discover default package.path, package.cpath?

Roberto Ierusalimschy
> What are you trying to prevent? What are you trying to protect?

This is a main question here. if you cannot trust LUA_PATH/LUA_CPATH,
you probably cannot trust LUA_INIT either. If you cannot trust LUA_INIT,
you cannot trust anything.

(Can you trust the script name? Are sure it is your scipt that is
running, and not something else? :-)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Discover default package.path, package.cpath?

Coda Highland
On Fri, Jan 4, 2019 at 6:38 AM Roberto Ierusalimschy
<[hidden email]> wrote:
>
> > What are you trying to prevent? What are you trying to protect?
>
> This is a main question here. if you cannot trust LUA_PATH/LUA_CPATH,
> you probably cannot trust LUA_INIT either. If you cannot trust LUA_INIT,
> you cannot trust anything.
>
> (Can you trust the script name? Are sure it is your scipt that is
> running, and not something else? :-)

"I think, therefore I am." Any test that evaluates "am I running?"
must always return true, for it would be a paradox to do otherwise.

/s/ Adam