Libinput Hit By Worrying Security Issues With Its Lua Plug-In System
7 points by laktak
7 points by laktak
As soon as I saw "sandbox escape" I immediately thought "I bet they let you load bytecode directly" and yep, that's how the attack works.
If you go look back at the history of vulnerabilities in Lua, almost all the sandbox escapes only happened in cases where the sandbox accepted bytecode. It's a design flaw in Lua IMO that the same load function accepts both code and bytecode, and one is safe while the other isn't. You can restrict it by passing an additional argument, but they really should be separate functions!
Lua 5.1 had no way to restrict the loading of byte code. Lua 5.2 was the version that added the extra parameter and the default was to allow both byte code and text to prevent code from breaking. Now, 5.2 had breaking changes [1] so IMHO, the Lua maintainers should have defaulted to loading only text, and having to opt-in to load binary code (instead of opting out of loading binary code).
I don't think having a separate function would have helped, but I don't have a good justification for this opinion.
[1] The big two were how global variables were handled internally (5.2 changed to a special table named ENV that could be changed vs. 5.1 that required a function call) and how modules worked (fall out from the global change). Mike Pall (author of LuaJIT) didn't agree with these changes, and thus we still, to this day, have this Lua 5.1/5x split.
I'm not really sure why these bugs warrant CVEs? They should be fixed of course as they are unintended behaviours, but as far as I can tell plugins are only loaded from /etc and /usr and you need to be root to write there already.
Could be shortened via phoronix (I didn't dig deeper) but yeah.
Reminds me of a kernel exploit talk 20y ago that amounted to "if you manage to get the people to load your poisoned kernel module then you're owned". Wow.
I’m always so tired when I see a breathless CVSS 9.8 bug that ends up being “if you enable this non-default setting that specifically says you should only enable it in trusted environments during testing because it disables authentication, authentication can be bypassed.”
The first one makes sense as it's a sandbox escape. I agree the second one probably didn't warrant one. Yes it requires root for installing plugins but people will inevitably install third party plugins as root that might be malicious.
I wonder if the maintainers had any input; getting really tired of researchers filing CVEs on behalf of maintainers without keeping them in the loop. I hope that isn't the case here.