Security considerations around package.{path,cpath}

[Augusto Stoffel <arstoffel@...>]

Hi,

This is mostly a discussion about packaging, either through LuaRocks or
OS package managers, but it also pertains to Lua itself.

As everybody knows, the default package.path and package.cpath include
"./?.lua" and other relative entries.  I noticed that neither LuaRocks
nor the Lua executables I installed in my Fedora system change this.
This means that it may be unsafe to run Lua programs if the current
directory contains evil files.  (This is of course undesirable; it's
guaranteed that just doing "ls" on such a directory will not lead to
trouble.)

The current directory is in fact the last one to be searched for lua
files or binary modules, which reduces the potential problems but
doesn't eliminate them.  Here's one legitimate example (from an existing
program in LuaRocks) with a security hole: suppose one wants to use the
cjson library if available, but not make it a strict requirement since
it can be tricky to compile.  Then one would do this:

    local json = pcall(require, "cjson") and require "cjson" or require "dkjson"

If cjson is not present on the system, an evil cjson.so in the local
directory could be executed.

As a comparison, Python also finds "local" modules, but in that case the
lookup is relative to the file containing the import statement, after
resolving symlinks.  This means that if a Python program is installed in
a system directory, it can never load modules outside system
directories.

One could argue that these are packaging bugs and should be solved
downstream, but perhaps Lua should be more helpful?  For instance, it
could include a "--safe-paths" switch to disable lookup in the current
directory, or maybe even have the opposite behavior, i.e. add a switch
to allow requiring modules from "./".

What do you think?