← Back to context

Comment by strenholme

15 hours ago

Thank you for your concern.

I fixed CVE-2014-5461 for Lunacy back in 2021:

https://github.com/samboy/lunacy/commit/4de84e044c1219b06744...

This is discussed here:

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/

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.

Yeah, 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.)

  • >>>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/2e154c163a465ee7ead...

    I patched it on my own in 2021:

    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

    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;
      }

    • > What makes you think I was using Lua in 2014? Seriously, do you even know how to use “git log”?

      ... It was fixed, upstream, in 2014. Thanks for not checking the number at the start of the CVE, before launching straight into attack mode.

      https://www.lua.org/bugs.html#5.2.2-1

      Which is the point. In 2020, when you added Lua, you added a vulnerability that had officially been fixed for six years. Because you vendored, and did not depend on any system package.

      > uint32_t is always 32-bit:

      Yah. Which is why I said 'int'.

      As in the assumptions you made here:

      https://github.com/samboy/LUAlibs/blob/master/rg32.c#L59

      1 reply →