lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> Has anybody investigated this further than I have?  Have I missed any
>  potential exploits?  Any comments, especially regarding the safety
> of luaopen_base?
In our Blue Frog application we have actually encountered a similar problem. In our application we dynamically download Lua scripts to perform some HTTP scripting activity (we've integrated CURL with Lua for that). We restrict all the access to the local file system (loading of either Lua scripts or libraries) with one exception -- loading (but not writing) of Lua scripts is possible ONLY from a reconfigured subdirectory (of the hosting application). We were able to achieve this with some hacking of the Lua global environment (I'm thankful for those who made it so easily  to change) and replacing some of the load functions with our own implementation (safesys) that validates that they operate within a "jail" subdirectory. 

We also wanted to achieve compatibility with the compat-5.1 module so we tweaked the global environment some more so it'll provide enough context for the compat module code. Below is an excerpt from an initialization code that runs BEFORE any other LUA code has a chance to execute. 

The entire code is can be downloaded from http://dev.bluesecurity.com/trac/blues/repos/wiki/DownloadPage 


Cheers,
Shmulik Regev
Blue Security


-- initialization code that removes

local funcs_to_stay = {clock=true,date=true,difftime=true,time=true}
table.foreach(os,function (k,v)
		    if type(v)=='function' and not funcs_to_stay[k] then
		      os[k] = nil
		    end
		  end)
-- clear the io library functions other than read/write. This is safe as
-- the disabling of the other functions restricts this