Bug #8122
openlua/output: improve handling of lib loading
Description
Since Suricata 8, external Lua modules must be explicitly whitelisted (e.g. lua.cpath=/usr/lib/lua/5.4/?.so).
It turned out that it is possible to bypass this security using the following in a Lua script setup function:
package.path = package.path .. ";/usr/share/lua/5.4/?.lua;/usr/share/lua/5.4/?/init.lua"
package.cpath = package.cpath .. ";/usr/lib/lua/5.4/?.so"
Files
JI Updated by Jason Ish 9 months ago
So this only affects output scripts, so its not that critical. The package global is not available in rules, and trying use it in rules does fail.
I guess the question is if we should allow it in output scripts, which aren't strictly sandboxed. I think ideally the path should be fixed to what the user sets, and perhaps not allow it to be set in an output script?
But a complex output script may break things into multiple files and want to set the path accordingly so it "just" works - something I often do with Python scripts.
My thought is to not make this private, see if we can even fix this while allowing output scripts to access to system modules, etc.
PA Updated by Philippe Antoine 8 months ago
- Tracker changed from Security to Bug
VJ Updated by Victor Julien 10 days ago
- Subject changed from Lua sandbox bypass to lua/output: improve handling of lib loading
- Private changed from Yes to No
As mentioned, lua output is not sandboxed.