Re: Userland Lua - concerns with require

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

Am 31.10.10 09:28, schrieb Steven Bellovin:
> 
> On Oct 31, 2010, at 10:17 30AM, Marc Balmer wrote:
> 
>> 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.
>>
> Vulnerabilities involving "." in search paths have a very long and
> sordid history.  The newest one, in Windows, came to serious notice
> just a few months ago (http://www.drdobbs.com/windows/227400009).  We
> should be very cautious about creating new instances.

Since several people expressed a bad gut feeling with having '.' in the
path, I decided to remove them for the Lua version in base, to avoid any
potential security issues (and further discussions... ;)

If someone needs the '.' in the path, it is easy enough to alter the path.

I hope this is a solution that everyone can live with, also if it means
trading a little bit of functionality for a bit more security.