4 ms·
Well, as you bundle Lua 5.1 (as Lunacy), instead of making a library and loading it, and you bundled the 2012 version, you're probably affected by CVE-2014-5461
by shakna 6mo ago
Well, as you bundle Lua 5.1 (as Lunacy), instead of making a library and loading it, and you bundled the 2012 version, you're probably affected by CVE-2014-5461 and others. Lua hasn't been security fix free.
- theamk 6mo agoUnless the service accepts Lua code from the internet (and that would be a completely insane thing), the CVE-2014-5461 will not apply. And while I have not reviewed every Lua CVE, I bet most (all?) of then require a specifically crafted code, or at least highly-complex user input (such as arbitrary json) It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.
- shakna 6mo agoIts important to maintain your dependencies, by say embedding Lua, rather than rebranding it and then claiming you have no security flaws. If I can find a CVE that _may_ affect the stack in five minutes, what _actual_ problems lurk there? You vendor Lua - thus, it _is_ your responsibility to review every Lua CVE. You've set yourself up as the maintainer by vendoring.
- selectively 6mo ago[flagged]
- strenholme 6mo agoYou weren’t replying to me. The parent poster made a good point—a vulnerability in Lua doesn’t mean software running Lua can necessarily be exploited—but, more to the point, I do update Lunacy and make sure it’s secure, just as I still take responsibility for verified important security holes in MaraDNS. See this, for example: https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2014-5461 https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2...
- ajross 6mo agoThat seems wildly naive in the post-XSS era. We've been here before, and that kind of analysis turns out to be wrong almost every time. "Well, sure, this component is insecure but an attacker can't reach it" is like a 50%+ positive signal for an unexpected privilege elevation bug.
- cesarb 6mo ago> It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version. Unfortunately, that's not enough. Even if the vulnerable parts of the code are not being built, heck even if they have been completely erased from the source code, the auditors will still insist that you're vulnerable and must immediately upgrade, or else they will give your software a failing grade.
- strenholme 6mo agoI should explain how MaraDNS uses Lua 5.1 (actually, Lunacy, my own fork with security bugs fixed as well as security hardening—including, yes, a patch against CVE-2014-5461), so you can get an idea of its attack surface. MaraDNS has three components: • MaraDNS, the authoritative server, which goes back all the way to 2001 • Deadwood, the recursive server, which was started back in 2007 • coLunacyDNS, which allows a DNS server to use Lua scripting; this didn’t exist until the COVID pandemic Neither MaraDNS nor Deadwood use Lunacy (except as a scripting engine for converting documents); only coLunacyDNS uses Lunacy. coLunacyDNS uses a sandboxed and security hardened version of Lunacy (and, yes, I would accept bugs where someone could escape that sandbox), and the Lua scripts which coLunacyDNS uses can only be controlled by a local user and there is no capability to run Lua scripts remotely.
- koolba 6mo ago> coLunacyDNS, which allows a DNS server to use Lua scripting; this didn’t exist until the COVID pandemic Why would a DNS server use Lua scripting? Is this for dynamically responding to requests rather than doing a pure lookup?
- strenholme 6mo agoIt’s useful for things like 10.1.2.3.ip4.internal style queries, or having a DNS server that always returns a given IP for any query given to it. More discussion is on the coLunacyDNS overview page: https://samboy.github.io/MaraDNS/coLunacyDNS/ https://samboy.github.io/MaraDNS/coLunacyDNS/
- strenholme 6mo agoThank you for your concern. I fixed CVE-2014-5461 for Lunacy back in 2021: https://github.com/samboy/lunacy/commit/4de84e044c1219b06744bfc0d80f6b8568e58e9a https://github.com/samboy/lunacy/commit/4de84e044c1219b06744... This is discussed here: https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2014-5461 https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2... In addition, I have done other security hardening with Lunacy compared to Lua 5.1: https://samboy.github.io/MaraDNS/webpage/lunacy/ https://samboy.github.io/MaraDNS/webpage/lunacy/ Now, I should probably explain why I’m using Lua 5.1 instead of the latest “official” version of Lua. Lua has an interesting history; in particular Lua 5.1 is the most popular version and the version which is most commonly used or forked against. Adobe Illustrator uses Lua 5.1, and Roblox uses a fork of Lua 5.1 called “luau”. LuaJIT is based on Lua 5.1, and other independent implementations of Lua (Moonsharp, etc.) are based on versions mostly compatible with Lua 5.1. Lua 5.1 has a remarkably good security history, and of course I take responsibility for any security bugs in the Lua 5.1 codebase since I use the code with the relatively new coLunacyDNS server (Lua 5.1 isn’t used with the MaraDNS or Deadwood servers). Lua 5.1 is used to convert documentation, but those scripts are run offline and the converted documents are part of the MaraDNS Git tree.
- shakna 6mo agoYeah, I've had patches submitted to Moonscript, Fengari, and luau. Don't need to sell on why 5.1 is useful. Each version is a new lang, not just a few fixes or niceties. I'm not convinced that vendoring, instead of embedding, is the right way. The patch landing in 2021, instead of 2014, being one of those concerns. (And you might want to recheck your assumption of how big 'int' will be, for rg32. C defines it in terms of minimum size, not direct size. int16_t isn't necessarily an alias.)
- strenholme 6mo ago>>>The patch landing in 2021, instead of 2014, being one of those concerns.<<< What makes you think I was using Lua in 2014? Seriously, do you even know how to use “git log”? I added Lua to MaraDNS in 2020: https://github.com/samboy/MaraDNS/commit/2e154c163a465ee7ead3f2827be782e9e3fd7c8c https://github.com/samboy/MaraDNS/commit/2e154c163a465ee7ead... I patched it on my own in 2021: https://github.com/samboy/MaraDNS/commit/efddb3a92b9cee30f115a42b6745f3c88b8e341a https://github.com/samboy/MaraDNS/commit/efddb3a92b9cee30f11... >>>you might want to recheck your assumption of how big 'int' will be uint32_t is always 32-bit: https://en.cppreference.com/c/types/integer https://en.cppreference.com/c/types/integer And, yes, this can be easily checked with a tiny C program: #include <stdint.h> #include <stdio.h> int main() { uint32_t foo = 0xfffffffd; uint64_t bar = 0xfffffffd; uint32_t a = 0; for(a=0;a<20;a++) { printf("%16llx:%16llx\n",foo++,bar++); } return 0; } If there’s a system where uint32_t is 64 bits, that’s a bug with the compiler (which isn’t following the spec), not MaraDNS. Are you going to make any other negative false implications about MaraDNS? Because you’re making a lot of very negative accusations without bothering to check first. Edit: Here’s a version of the above C program which works in tcc 0.9.25: #include <stdint.h> #include <stdio.h> void shownum(uint64_t in) { int32_t a; for(a=60;a>=0;a-=4) { int n = (in >> a) & 0xf; if(n < 10) {printf("%c",'0'+n);} else {printf("%c",'a'+(n-10)); } } return; } int main() { uint32_t foo = 0xfffffffd; uint64_t bar = 0xfffffffd; uint32_t a = 0; for(a=0;a<20;a++) { shownum(foo++); printf(":"); shownum(bar++); puts(""); } return 0; }