MaraDNS security report thread

[samboy]

If you believe you have found a security issue in MaraDNS, please report it at https://github.com/samboy/MaraDNS/security/advisories

This thread is now locked. Thank you for your understanding.

[PetrolDriver]

MIPS compiler for OpenWrt has problem with undeclared identifiers in rng/rng-alg-fst.c file
I tried 3.4.01 and 3.5.0021.

error message:

_mips-openwrt-linux-musl-gcc -O2 -Wall -DSELECT_PROBLEM    -c -o ../rng/rng-alg-fst.o ../rng/rng-alg-fst.c
../rng/rng-alg-fst.c: In function 'rngKeySetupEnc':
../rng/rng-alg-fst.c:104:34: error: 'Te4' undeclared (first use in this function); did you mean 'STe4'?
                                 (Te4[(temp >> 16) & 0xff] & 0xff000000) ^
                                  ^~~
                                  STe4
../rng/rng-alg-fst.c:104:34: note: each undeclared identifier is reported only once for each function it appears in
../rng/rng-alg-fst.c:125:27: error: 'Te0' undeclared (first use in this function); did you mean 'Te4'?
                 STe0[i] = Te0[i];
                           ^~~
                           Te4
../rng/rng-alg-fst.c:126:27: error: 'Te1' undeclared (first use in this function); did you mean 'Te0'?
                 STe1[i] = Te1[i];
                           ^~~
                           Te0_

solution for rng/rng-alg-fst.c

unsigned char Sc[256];
/* adding this */
u32 Te0[256];
u32 Te1[256];
u32 Te2[256];
u32 Te3[256];
u32 Te4[256];

u32 STe0[256];
u32 STe1[256];
u32 STe2[256];
u32 STe3[256];
u32 STe4[256];
#define SWAP(x) (_lrotl(x, 8) & 0x00ff00ff | _lrotr(x, 8) & 0xff00ff00)
.
.
.

[samboy]

This is not a security bug. When cross-compiling, make_32bit_tables has to be compiled for the host compiling program. See below.

[samboy]

This is not a security bug. When cross-compiling, make_32bit_tables has to be compiled for the host compiling program, e.g. do this on the compiling host

cc -o make_32bit_tables make_32bit_tables.c
./make_32bit_tables > rng-32bit-tables.h

As an aside, you have caught a security nuisance if not security hole: This is a slow ugly hack to AES to try and make it less vulnerable to cache timing attacks. The real solution is to replace that with RadioGatún[32] (or another cryptographic strong pseudo-random number generator) like what Deadwood does.

[vagrantc]

I wasn't sure where to ask this, and it might have some security implications, so, here goes...

What is the purpose of embedding a random number in deadwood at build time?

MaraDNS/deadwood-github/src/Makefile.ubuntu2004

Line 25 in 437900d

# Since some systems may not have /dev/urandom (Windows, *cough* *cough*), we

The comment suggests that this random number is mainly targeted at windows, does it fall back to this embedded random prime number if /dev/urandom is not present at runtime? Would it be possible to fail hard if /dev/urandom wasn't available instead for environments where /dev/urandom is expected to be present (e.g. most linux distrubitons)?

Embedding a random number at build time means for a given package build on many software distributions, all users of that version get the same "random" number.

It also means that it is essentially impossible to build upstream maradns bit-for-bit identically, even if nothing in the build environment has changed since a previous build:

https://reproducible-builds.org

The Debian package builds reproducibly by patching it to use the same "random" number every time:

https://sources.debian.org/src/maradns/2.0.13-1.4/debian/patches/deadwood_makefile.patch/
https://sources.debian.org/src/maradns/2.0.13-1.4/debian/DwRandPrime.h/

... but this could have some dangerous consequences if the random number is indeed needed for security sensitive purposes.

I was looking into this issue for GNU Guix, and started a thread about it:

https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00110.html
https://lists.gnu.org/archive/html/guix-devel/2022-06/threads.html#00110

Would very much appreciate some guidance with someone familiar with the maradns codebase as to what the security implications are, and suggestions for how to go about making the builds reproducible without introducing security issues!

Thanks!

[samboy]

I wrote the code, back in the early days of Deadwood, in 2007, when I became aware (in 2007!) of the 2011 hash randomization attack (where an attacker can have multiple entries use the same hash bucket). So, I did the following:

• I invented a non-cryptographic hash compression algorithm which doesn’t have predictable outputs
• Since it required multiplying by a prime number, I came up with a quick and dirty bit of code to find a 32-bit prime number. The code is slightly slow, so I wanted to run the code when building, not running Deadwood.
• In 2010, I updated that homegrown hash compression algorithm to also add a random number when compressing the input, and calculating another 32-bit random number when Deadwood starts.
• I believe the hash compression algorithm is protected from hash bucket collision attacks, even if Deadwood is patched to make MUL_CONSTANT a constant number, since the add constant remains random.
• The reason for a random MUL_CONSTANT is multi-pronged security. If someone is on a system where /dev/urandom has an issue with low quality random numbers, Deadwood’s hash compression might still be secure from hash bucket collision attacks. In addition, on embedded systems, calculating a random 32-bit prime number every time Deadwood starts may be too computationally expensive.
• If one’s coding style can’t have a random 32-bit number in a build, make MUL_CONSTANT an unchanging number like 1748294267 (the number I use for Windows builds of Deadwood). Deadwood will still be secure from hash bucket collision attacks except in the very rare corner case of /dev/urandom not giving out good random numbers.
• If I were to write the code again today, I would use half-siphash 1/3 instead of the homegrown hash compression algorithm I used (back in 2007, cryptographically secure hash bucket collision algorithms didn’t exist). Indeed, that’s what I did with coLunacyDNS

[samboy]

I have updated Deadwood to no longer regenerate this prime number every time it is built unless the Makefile.randomprime file is invoked.

[samboy]

Locking discussion to stop spam bots. If you have an issue, start a new discussion.

[samboy]

Unlocking...it’s important to make it as easy as possible to report security bugs. I’ll delete support requests improperly placed here, however.

[samboy]

Locked again. Report vulnerabilities here: https://github.com/samboy/MaraDNS/security/advisories