Auto chdir requires static link of lua library - ideas to revise

[dave-k-evad]

I'm considering adding an optional build-time feature of dynamically linking the lua library instead of staticly linking to it. This will improve the security and reliability of premake, because then updates to the lua library can be more frequent and automatically done by distro maintainers.

The one sticking point is where to move the calls of do_chdir() in src/lua_auxlib.c:chunk_wrapper(). Any advice on how the chdir calls can be preserved?

Perhaps I can override the dynamically linked function, but at least one article about this indicates that it's necessary to place a proxy dll that would pass through every call to the target dll. Or, should I register callbacks at script entry and exit? What is the Right Way to do it?

Thanks.

[samsinsane]

What is the Right Way to do it?

The way that works on all platforms, doesn't add any maintenance burdens, and doesn't break anything when linking a different Lua runtime. While that might seem unreasonable, we're not a huge team and what you're putting forward does not sound like a trivial thing to support. Our Lua scripts had to be modified when we moved from Lua 5.1 to 5.3, so I imagine we'll have people reporting issues using Lua 5.1 or LuaJIT.

Unfortunately, Premake can't really have arbitrary Lua version changes, we might be able to upgrade in the 5.3 line, but other than a dozen commits we're basically at the end of the 5.3 line with no future releases of Lua 5.3 planned or expected. It would be a lot easier to just get those 14 commits.

---

This will improve the security and reliability of premake, because then updates to the lua library can be more frequent and automatically done by distro maintainers.

This isn't really the point of your post, but I'm not sure this really holds true. Lua 5.3.3 was released in 2016 and was first packaged in Ubuntu 17.04 and has been the Lua 5.3 version in every release until Ubuntu 22.04 - 5 years later - which upgraded to 5.3.6, released in 2020. Lua 5.3.4 was released before Ubuntu 17.04 shipped too, so it shipped with an out of date version of Lua 5.3 and then never updated, nor did 17.10, 18.04, 18.10, 19.04, 19.10, 20.04, 20.10, 21.04, or 21.10. 10 versions of Ubuntu shipped with an out of date version of Lua 5.3, and continue(d) to only provide that out of date version.

[dave-k-evad]

What is the Right Way to do it?
The way that works on all platforms, doesn't add any maintenance burdens, and doesn't break anything when linking a different Lua runtime.

Based on what you've written, you seem to prefer to continue using a static lua library. Security and reliability advice recommends that bundled dependencies not be used.

Unfortunately, Premake can't really have arbitrary Lua version changes, we might be able to upgrade in the 5.3 line, but other than a dozen commits we're basically at the end of the 5.3 line with no future releases of Lua 5.3 planned or expected.

I agree. I am only planning to use an updated version of lua5.3. Later, ideally the premake scripts are updated for lua5.4 so that security updates don't need to be backported.

This will improve the security and reliability of premake, because then updates to the lua library can be more frequent and automatically done by distro maintainers.

This isn't really the point of your post, but I'm not sure this really holds true. Lua 5.3.3 was released in 2016 and was first packaged in Ubuntu 17.04 and has been the Lua 5.3 version in every release until Ubuntu 22.04 - 5 years later - which upgraded to 5.3.6, released in 2020.

Distribution maintainers regularly backport security updates to the older versions of software, provided that they aren't staticly linked. Sometimes security updates for LTS releases of distros are delayed until the next point release, but that's on the order of months, not years. Here are some examples of known security vulnerabilities in lua5.3, which likely affect premake.

CVE-2019-6706
CVE-2020-24370
CVE-2021-43519

[samsinsane]

In the context of Premake do those CVEs apply? I appreciate the security concern, but surely os.execute is much worse than those CVEs? If an attacker has to run Lua code to trigger those CVEs, then they can run os.execute and then run anything on the host machine?

[dave-k-evad]

In the context of Premake do those CVEs apply?

Please consider that the CVEs that I have listed here are only those that I found with a quick spot-check, and there are likely others that haven't been patched in premake's bundled lua library.

I would argue that the CVEs listed do apply in a local build environment. It's easy to audit an application's build process for calls to os.execute and similar functions with a simple plaintext search. But, it is not easy to audit for code that has indirect effects of exploiting a vulnerability, as it requires understanding the nuances of all of the code in premake and the packages that build with premake, as well as the security vulnerabilities. This means it's a useful attack surface for stealthy malware.

And, keep in mind that new vulnerabilities will probably be discovered in the future, and we want the update process to be fast and easy for the users so that we can't be blamed for making their systems insecure. As stavrok said in #1717 , "Our dependencies haven't been updated in a while, so we're not up on the latest fixes and security updates. It is starting to cause user acceptance issues."

If you want to save yourself and the users of premake a lot of effort (ie. avoiding auditing all applications that use premake) then you can follow the advice of the security professionals, keep all dependencies up to date, and don't bundle dependencies.

Anyway, I'm not telling you what to do. I'm just asking for assistance from someone who knows where to move the chdir() calls.