Upstream here. I should probably summarize the security issues post
2.0.13; MaraDNS is the authoritative server and Deadwood is the
recursive server:
- A theoretical issue with the cryptographic code which doesn’t affect
gcc and clang compiles of Deadwood.
- An issue where a clever attacker could had kept a record in the
cache longer than desired in a fully recursive instance of Deadwood.
- An issue where a clever attack could make Deadwood perform around
500 queries to resolve a given name, if they can control the query and
responses Deadwood gets. In the fix, that number was reduced to 83.
None of these are serious security issues; I would be comfortable
using a non-Recursive instance of MaraDNS 2.0.13 on a public network,
but they are “it’s probably worth updating” security issues. I should
point out that MaraDNS 3 is fully compatible with MaraDNS 2
configuration files and the number jump was done to keep Deadwood’s
and MaraDNS’s version numbers in sync.
In terms of the upgrade, there are two branches to consider:
- The very stable 3.4 branch, where the fixes are by and large
security and other serious fixes. This branch, which was dormant for
about three years, recently had a flurry of updates for minor security
and Y2038 fixes. [1] The majority of the updates are made as patches
which can be applied to older versions, if Debian wants to take the
“patch older software” route. My plan is to keep this branch dormant
again unless another security issue comes up. In particular, this
branch is generally *not* updated to fix resolution issues with the
Deadwood recursive resolver, unless it’s something huge like
amazon.com not resolving.
- The less stable 3.5 branch. This is the continuous integration
version of MaraDNS; features are added and there’s no “frozen” branch.
Automated testing is done once a day whenever the Git tree changes and
I frequently make new releases when a given Git checkout passes
automated tests. Effort is made to keep older configuration files
compatible, so we don’t get the situation where configuration files
need to be revised to apply a security update.
[1] Other stuff was changed too. I changed a bunch Makefiles and
filenames in MaraDNS 3.4 so that it will compile with a mostly-POSIX
compliant implementation of `make`; POSIX actually didn’t mandate `-`
in make targets (it will in the next 202X POSIX release); I added
min_ttl to Deadwood so it remains semi usable as a fully recursive DNS
server on the modern Internet.
On Mon, Nov 21, 2022 at 5:03 AM Moritz Muehlenhoff wrote:
>
> Source: maradns
> Version: 2.0.13-1.4
> Severity: serious
>
> The last maintainer upload was in 2015 and the version currently in the
> archive is way behind current upstream releases (which is at 3.4.07),
> we have plenty of maintained DNS servers, keep it out of testing (
> and if noone picks it up, remove it from the archive).
>
