Re: Userland Lua - concerns with require

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

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.

                --Steve Bellovin, http://www.cs.columbia.edu/~smb