Re: Userland Lua - concerns with require

[Marc Balmer <mbalmer%NetBSD.org@localhost>]

Am 31.10.10 07:26, schrieb Bernd Ernesti:

> On Thu, Oct 28, 2010 at 09:21:36AM +0200, Marc Balmer wrote:
>> Am 27.10.10 23:37, schrieb Phil Nelson:
>>> On Wednesday 27 October 2010 2:21:34 pm Marc Balmer wrote:
>>>> I will change the default path specifications.
>>>
>>> What specific change?  Removing . or moving it to the end?
>>> I'd argue that removing . is the correct thing to do, not
>>> just moving it to the end if you are worried about security.
>>> But from my knowledge of lua it expects . in the path.
>>>
>>> Your two previous posts didn't convey the details of the solution.
>>
>> After considerations, email exchange with the makers of Lua, and testing
>> realword systems I think probably the best thing to do is to move the
>> '.' parts to the end of the list:
>>
>> The obvious security risk is that someone puts a Lua file in your
>> homedirectory with the name of an _existing_ module, e.g. some database
>> adapter, and tricks you into running this code instead.
>>
>> When '.' is moved to the end of the list, this kind of exploit is no
>> longer possible.  This is also what the makers of Lua did for the next
>> release, Lua 5.2.
>>
>> I am a bit hesitant right now to remove the '.' entries completely, I am
>> still trying to assess the consequences.  That said, I am open for (well
>> reasoned) opinions.
> 
> So you still plan to import it with having '.' in the path which means we
> will now get something new in the base system which we know that it could
> cause security issues.

You write "which we know that it could cause security issues", but that
is only a claim, for which I have my doubts.  A realistic attack
scenario should be shown (with a patch where the '.' is at the end), atm
I don't see that:

The (hypothetical) attack would be to trick a user to 'require'
something that is not there in the system path, but in some arbitrary
directory.  So don't 'require' stuff that is not there, which is easy
enough to accomplish.  This is also a good reason, not to include
/usr/pkg in the path, because a required Lua module could all to easily
have been removed or not been installed in the first place.

I agree that original path setup, where '.' is at the beginning of the
path, can cause real security issues, because you "only" have to trick a
user to 'require' something that _is_ there.

Removing the '.' from the path can have some severe consequences, from a
usability standpoint.

The path, btw, is not a read only variable, it can be changed:

- The environment variable LUA_PATH and LUA_CPATH can be set
- From Lua, the package.path and package.cpath variables can be set

So yes, atm I am not convinced that removing the '.' from the path is
the right thing to do.