summaryrefslogtreecommitdiffstats
path: root/wscript_build.py
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-02-05 16:20:37 +0100
committerwm4 <wm4@nowhere>2020-02-06 11:59:24 +0100
commitcce7062a8a6b6a3b3666aea3ff86db879cba67b6 (patch)
treecebff77cd6a3dd969d738301c97a9609f99841a6 /wscript_build.py
parent65cd9efa850faaedb9f866632feb9fee2ef71462 (diff)
downloadmpv-cce7062a8a6b6a3b3666aea3ff86db879cba67b6.tar.bz2
mpv-cce7062a8a6b6a3b3666aea3ff86db879cba67b6.tar.xz
lua: fix highly security relevant arbitrary code execution bug
It appears Lua's package paths try to load .lua files from the current working directory. Not only that, but also shared libraries. WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING? mpv isn't setting this package path; currently it's only extending it. In any sane world, this wouldn't be a default. Most programs use essentially random working directories and don't change it. I cannot comprehend what bullshit about "convenience" or whatever made them do something this broken and dangerous. Thousands of programs using Lua out there will try to randomly load random code from random directories. In mpv's case, this is so security relevant, because mpv is normally used from the command line, and you will most likely actually change into your media directory or whatever with the shell, and play a file from there. No, you don't want to load a (probably downloaded) shared library from this directory if a script try to load a system lib with the same name or so. I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the Debian version) put "./?.lua" at the end, but in any case, trying to load a module that doesn't exist nicely lists all package paths in order, and confirms it tries to load files from the working directory first (anyone can try this). Even if it didn't, this would be problematic at best. Note that scripts are _not_ sandboxed. They're allowed to load system libraries, which is also why we want to keep the non-idiotic parts of the package paths. Attempt to fix this by filtering out relative paths. This is a bit fragile and not very great for something security related, but probably the best we can do without having to make assumptions about the target system file system layout. Also, someone else can fix this for Windows. Also replace ":" with ";" (for the extra path). On a side note, this extra path addition is just in this function out of laziness, since I'd rather not have 2 functions with edit the package path. mpv in default configuration (i.e. no external scripts) is probably not affected. All builtin scripts only "require" preloaded modules, which, in a stroke of genius by the Lua developers, are highest priority in the load order. Otherwise, enjoy your semi-remote code execution bug. Completely unrelated this, I'm open for scripting languages and especially implementations which are all around better than Lua, and are suited for low footprint embedding.
Diffstat (limited to 'wscript_build.py')
0 files changed, 0 insertions, 0 deletions