Bug#1024561: Unmaintained, keep out of stable

[Sam Trenholme]

[1] RFC8482 responds to ANY in such as way as to not break Qmail

On Sat, Nov 26, 2022 at 10:34 AM Sam Trenholme  wrote:
>
> Upstream here again.  I have released MaraDNS 3.5.0030 and 3.4.09 with
> a security update: MaraDNS now fully supports RFC8482, which means
> MaraDNS no longer supports ANY records. [1] While MaraDNS does not
> have long packet support, this removes one possible denial of service
> amplification path.
>
> If someone can not step up to plate to maintain MaraDNS for Debian, we
> should deprecate and eventually remove the package.
>
> I may end up making my own .deb files for MaraDNS.
>
> -- Sam
>
> 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).
> >

Bug#1024561: Unmaintained, keep out of stable

[Sam Trenholme]

Upstream here again.  I have released MaraDNS 3.5.0030 and 3.4.09 with
a security update: MaraDNS now fully supports RFC8482, which means
MaraDNS no longer supports ANY records. [1] While MaraDNS does not
have long packet support, this removes one possible denial of service
amplification path.

If someone can not step up to plate to maintain MaraDNS for Debian, we
should deprecate and eventually remove the package.

I may end up making my own .deb files for MaraDNS.

-- Sam

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

Bug#1024561: Unmaintained, keep out of stable

[Sam Trenholme]

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

Bug#936992: Upstream here: Please close this bug

[Sam Trenholme]

I have gone to the bother of converting bind2csv2.py to be a python2 and
python3 polyglot. Keep in mind that this script does not work with a good
number of real-world BIND zonefiles: But it will now run in python3 the
same way it runs in python2 (converting a strict subset of BIND zone files).

This updated bind2csv2.py file is currently only in GitHub, at this
location:

https://raw.githubusercontent.com/samboy/MaraDNS/master/tools/bind2csv2.py

For your convenience, this will close the following bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936992

As an aside, the current stable version of MaraDNS is 3.4.01, and I will
not update bind2csv2.py in the stable release until I get a chance to
update how the tarball is made; one thing I plan on doing is making the Git
version of MaraDNS the one source of truth from which all tarballs are
created, and set up some continuous integration scripts so I can go from
the Git tree to source code tarballs in one command, and from source code
tarballs to Windows binaries from another single command run in Windows +
mingw/msys.  But that will happen in the future.

For now, again, the solution is not to remove MaraDNS from Debian, but to
find someone willing to maintain the Debian package. But,  open source
economics being what it is, since there’s no money on the table, that’s not
going to happen in the real world. Did I mention that there’s a theoretical
security issue in MaraDNS 2.0.13? I’ve fixed it well over a year ago.

Up to date information on MaraDNS’s security is available at
https://maradns.samiam.org/security.html

On Sat, Nov 2, 2019 at 6:54 AM Sam Trenholme  wrote:

> Upstream here: Please close this bug.
>
> One can close this bug by removing the Python2 dependency.
>
> MaraDNS does not use any Python, neither Python2, nor Python3, to build
> the code.
>
> MaraDNS does not use any Python to install the code.
>
> MaraDNS does not use any Python to run the authoritative daemon, nor the
> recursive daemon, nor the DNS-over-TCP daemon, nor the tool for making
> recursive DNS queries.
>
> Python is *only* used for the bind2csv2.py tool which converts Bind zone
> files in to MaraDNS zone files. One can safely remove this tool without
> affecting MaraDNS’s functionality.
>
> Thank you.
>

Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports

[Sam Trenholme]

Thank you for verifying this is not a bug. I would rather have a false
bug report than have a real security issue out there that I’m not
aware of.

I should explain why the MaraDNS code is so messy and hard to follow:

Back in 2001, there was precisely one and only one open-source DNS
server: BIND. This was an issue, so there was a call to arms to have
another open source DNS server out there:
http://old.lwn.net/2001/0208/

That in mind, I quickly wrote up a DNS server; within two months I had
a usable authoritative server, and within a year I had a usable
recursive server. This rapid development came at a cost: The code
worked, was remarkably secure considering how quickly I wrote it, but
it was a mess to maintain. I had planned for years to rewrite MaraDNS,
and five years after the initial recursive server, I started a project
to rewrite the recursive code. My plan was to have a recursive server
within a year; while I had a usable caching server with cleaner code
within six months, it took me three years to make it a fully recursive
server.

My original plan was to rewrite the recursive component, than rewrite
the authoritative component. That never happened, for a number of
reasons, including the fact that DjbDNS became open-source after I
started MaraDNS 2.0’s recursive server, and NSD/Unbound came on to the
scene. With the excellent Knot DNS and Knot Resolver now also carrying
the torch for open source DNS servers, and with my life having a lot
less free time than I did a decade and a half ago when I started
MaraDNS, MaraDNS is in deep freeze maintenance mode.

I still take responsibility for security issues in the code I wrote a
long time ago, since there’s a contingent of users who feel MaraDNS is
more lightweight on “low end boxes” such as virtual machines with only
128 megs of memory (and are willing to give up DNSsec support to have
something that lightweight). But, beyond that, I don’t have time to
even fix things like resolution issues caused because the way DNS
servers handle out-of-bailiwick glue in CNAME records has changed
since 2001. Forget about adding DNSsec to MaraDNS.

Anyway, I do welcome security reports to MaraDNS and do take them very
seriously. There may not be a “packet of death” bug in the MaraDNS
codebase — João Antunes did a pretty through audit of the
authoritative codebase back in 2007 and probably would have found a
“packet of death” back then if there was one.

— Sam

On Mon, Dec 5, 2016 at 5:27 AM, Ondřej Surý <ond...@sury.org> wrote:
> Sam and others,
>
> I most deeply apologize, you are right in your assessment.
>
> I somehow missed the extra four additional sanity checks at the
> beginning of the getudp() function that seems to catch the error
> conditions on those input buffers.
>
> Cheers,
> --
> Ondřej Surý <ond...@sury.org>
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
> fast DNS(SEC) resolver
> Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
> pečení chleba všeho druhu
>
> On Sat, Dec 3, 2016, at 16:47, Sam Trenholme wrote:
>> CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug
>> reports.
>>
>> Here’s the deal: The reporter had to patch MaraDNS before he was able
>> to crash her.
>>
>> The patch, however, treats MaraDNS’ special buffer-overflow-resistant
>> “js_string” as if it were an ordinary string — but it’s not. Here’s
>> the offending code patched in to MaraDNS from the reporter’s “bug
>> report”:
>>
>> sock_num = read(0, incoming, 512);
>>
>> As per the man page for read:
>>
>> ssize_t read(int fd, void *buf, size_t count);
>>
>> DESCRIPTION
>>read()  attempts to read up to count bytes from file descriptor fd
>>into
>>the buffer starting at buf.
>>
>> However, incoming is not a raw string buffer: It’s a special js_string
>> object which MaraDNS uses to be buffer overflow resistant, as can be
>> seen here in server/MaraDNS.c:
>>
>> int main(int argc, char **argv) {
>>
>> js_string *mararc_loc = 0, *errors = 0,
>>   *bind_address = 0, *ipv6_bind_address = 0,
>>   *csv2_synthip_address = 0,
>>   *ipv4_bind_address = 0, *incoming = 0,
>>   *uncomp = 0, *verbstr = 0;
>>
>> The js_string structure (I guess I would call it an object here in
>> 2016) is defined in libs/JsStr.h:
>>
>> typedef struct {
>> unsigned char *string;   /* Actual physical string */
>> unsigned int unit_size;  /* The size of a single character in the
>> string */
>> unsigned int unit_count; /* The length of the string, in units */
>> un

Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports

[Sam Trenholme]

CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports.

Here’s the deal: The reporter had to patch MaraDNS before he was able
to crash her.

The patch, however, treats MaraDNS’ special buffer-overflow-resistant
“js_string” as if it were an ordinary string — but it’s not. Here’s
the offending code patched in to MaraDNS from the reporter’s “bug
report”:

sock_num = read(0, incoming, 512);

As per the man page for read:

ssize_t read(int fd, void *buf, size_t count);

DESCRIPTION
   read()  attempts to read up to count bytes from file descriptor fd into
   the buffer starting at buf.

However, incoming is not a raw string buffer: It’s a special js_string
object which MaraDNS uses to be buffer overflow resistant, as can be
seen here in server/MaraDNS.c:

int main(int argc, char **argv) {

js_string *mararc_loc = 0, *errors = 0,
  *bind_address = 0, *ipv6_bind_address = 0,
  *csv2_synthip_address = 0,
  *ipv4_bind_address = 0, *incoming = 0,
  *uncomp = 0, *verbstr = 0;

The js_string structure (I guess I would call it an object here in
2016) is defined in libs/JsStr.h:

typedef struct {
unsigned char *string;   /* Actual physical string */
unsigned int unit_size;  /* The size of a single character in the string */
unsigned int unit_count; /* The length of the string, in units */
unsigned int max_count;  /* The maximum allowable size of the string,
   also in units */
int encoding;   /* The type of language/encoding the string is in */
int is_good;/* This is checked to make sure the data structure is
   sane */
} js_string;

Point being, if we patch MaraDNS to treat this structure as a raw
buffer instead of a structure, we will be able to crash MaraDNS — but
that doesn’t mean we have found a UDP packet of death which will crash
unpatched MaraDNS 2.0.13.

I appreciate that people are performing security research with
MaraDNS, and the fact that researchers need to resort to patching
MaraDNS before crashing her indicates that, a decade and a half later
MaraDNS is still a usable DNS server with a strong security record.

Bug#844121: Remote crash in MaraDNS 2.0.13

[Sam Trenholme]

This email concerns CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302.

I have written a utility to send the packets that supposedly remotely crash
MaraDNS to MaraDNS via UDP. The packets do not crash MaraDNS when sent over
the network; I can only crash MaraDNS with the offending packets by using
the reporter’s patch to update MaraDNS to get DNS packets via standard
input, and only in my 64-bit Cygwin development environment.

I am closing this issue; I will open this again if someone can come up with
an actual "send this UDP packet and MaraDNS crashes" recipe. Please let me
know which OS and which processor architecture the crash happens on, but if
the OS is anything besides CentOS6 or the architecture anything besides x86
(32-bit) or amd_64/x86-64 (64-bit), I will not be able to address the
concern without a patch being provided.

Further discussion of this matter can be done by either replying to this
email, or by adding a note to https://github.com/samboy/MaraDNS/issues/33

Again, I will reopen this issue as a critical security issue if and only if
someone can reproduce this concern via an actual UDP packet sent to
MaraDNS. Please provide the source code of the program generating the
packet of death, or use the program I wrote to attempt to reproduce this
issue at
https://github.com/samboy/MaraDNS/blob/1dba9f49e9b6f788cf602695478edcb094a0cc06/sqa/sendpacket.c
(sqa/sendpacket.c if you clone the Github tree as of 2016-12-03).

Ondrej: If you were to provide a patch, or even a usable stack trace -- or
even just let me know on which distribution and architecture you're seeing
the issue (sorry, but I couldn't get a usable core file or stack trace in
Cygwin-64, and no crash at all in CentOS6-32bit) -- I will open up a GitHub
bug about the issue. I agree there is probably a bug in MaraDNS -- but I
will not treat this as an "all hands on deck" packet-of-death level
security bug until we can send an actual packet of death over UDP to kill
MaraDNS.

On Sat, Dec 3, 2016 at 6:04 AM, Sam Trenholme <mara...@gmail.com> wrote:

> Github bug: https://github.com/samboy/MaraDNS/issues/33
>
> Please go here to get the latest updates from upstream about this issue.
>
> On Sat, Dec 3, 2016 at 5:52 AM, Sam Trenholme <mara...@gmail.com> wrote:
>
>> Hello there,
>>
>> I have just become aware of this bug. Right now, I can reproduce the
>> crash in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit
>> CentOS6 development environment where I would actually be able to get a
>> full stack trace (which was not provided in the original bug report). Until
>> I can get a setup to reproduce the crashes in a manner which lets me have
>> full stack traces, I will not be able to make the appropriate patches to
>> fix the bug.
>>
>> There is no money on the table, and I have stopped actively developing
>> MaraDNS every since becoming a single parent with a full-time job. Welcome
>> to the world of open source economics: Since I’m not getting paid for my
>> time writing open-source software, I have very little time to devote to
>> MaraDNS.
>>
>> I will open up a GitHub bug so that users know I am aware of the bug. I
>> do not have a time frame for fixing the issue at this time. Hopefully by
>> the end of the year.
>>
>> -- Sam
>>
>> On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello <luci...@debian.org>
>> wrote:
>>
>>> Source: maradns
>>> Severity: grave
>>> Version: 2.0.13-1.2
>>> Tags: security upstream
>>>
>>> Hi,
>>>
>>> The following vulnerability was published for MaraDNS:
>>> http://seclists.org/oss-sec/2016/q4/411
>>>
>>> No CVE is was assigned yet, but the request was made in that thread.
>>> If you fix the vulnerability please also make sure to include the
>>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if
>>> it is
>>> assigned soon.
>>>
>>> Please adjust the affected versions in the BTS as needed.
>>>
>>> Regards,luciano
>>>
>>>
>>
>

Bug#844121: Remote crash in MaraDNS 2.0.13

[Sam Trenholme]

Github bug: https://github.com/samboy/MaraDNS/issues/33

Please go here to get the latest updates from upstream about this issue.

On Sat, Dec 3, 2016 at 5:52 AM, Sam Trenholme <mara...@gmail.com> wrote:

> Hello there,
>
> I have just become aware of this bug. Right now, I can reproduce the crash
> in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit CentOS6
> development environment where I would actually be able to get a full stack
> trace (which was not provided in the original bug report). Until I can get
> a setup to reproduce the crashes in a manner which lets me have full stack
> traces, I will not be able to make the appropriate patches to fix the bug.
>
> There is no money on the table, and I have stopped actively developing
> MaraDNS every since becoming a single parent with a full-time job. Welcome
> to the world of open source economics: Since I’m not getting paid for my
> time writing open-source software, I have very little time to devote to
> MaraDNS.
>
> I will open up a GitHub bug so that users know I am aware of the bug. I do
> not have a time frame for fixing the issue at this time. Hopefully by the
> end of the year.
>
> -- Sam
>
> On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello <luci...@debian.org>
> wrote:
>
>> Source: maradns
>> Severity: grave
>> Version: 2.0.13-1.2
>> Tags: security upstream
>>
>> Hi,
>>
>> The following vulnerability was published for MaraDNS:
>> http://seclists.org/oss-sec/2016/q4/411
>>
>> No CVE is was assigned yet, but the request was made in that thread.
>> If you fix the vulnerability please also make sure to include the
>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if
>> it is
>> assigned soon.
>>
>> Please adjust the affected versions in the BTS as needed.
>>
>> Regards,luciano
>>
>>
>

Bug#844121: Remote crash in MaraDNS 2.0.13

[Sam Trenholme]

Hello there,

I have just become aware of this bug. Right now, I can reproduce the crash
in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit CentOS6
development environment where I would actually be able to get a full stack
trace (which was not provided in the original bug report). Until I can get
a setup to reproduce the crashes in a manner which lets me have full stack
traces, I will not be able to make the appropriate patches to fix the bug.

There is no money on the table, and I have stopped actively developing
MaraDNS every since becoming a single parent with a full-time job. Welcome
to the world of open source economics: Since I’m not getting paid for my
time writing open-source software, I have very little time to devote to
MaraDNS.

I will open up a GitHub bug so that users know I am aware of the bug. I do
not have a time frame for fixing the issue at this time. Hopefully by the
end of the year.

-- Sam

On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello  wrote:

> Source: maradns
> Severity: grave
> Version: 2.0.13-1.2
> Tags: security upstream
>
> Hi,
>
> The following vulnerability was published for MaraDNS:
> http://seclists.org/oss-sec/2016/q4/411
>
> No CVE is was assigned yet, but the request was made in that thread.
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if it
> is
> assigned soon.
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,luciano
>
>

Bug#665012: CVE-2012-1570: maradns deleted domain record cache persistance flaw

[Sam Trenholme]

Upstream here.  It's a six-line patch:

http://maradns.org/download/patches/security/maradns-1.4.11-ghostdomain.patch

This should not be too difficult to apply.

Also, the security report is somewhat inaccurate.  Both MaraDNS and
Deadwood were never vulnerable to the Ghost Domain bug as described
in the original report...something said report points out. However,
the programs were vulnerable to caching records with a long
TTL...easily fixed by capping TTLs to only last one day.

Finally, MaraDNS 1.4 will no longer be supported by me on June 21,
2015.  Please be sure to update all MaraDNS packages to 2.0 before
then.

- Sam

--- maradns-1.4.11/server/recursive.c   2012-01-13 13:39:01.0 -0600
+++ maradns-1.4.12/server/recursive.c   2012-03-17 09:52:27.0 -0600
@@ -1370,6 +1370,10 @@
 ttl = js_readuint32(server_reply,offset);
 if(ttl == JS_ERROR)
 return JS_ERROR;
+if(ttl  20)
+ttl = 20;
+if(ttl  86400) /* One day; Ghost domain fix */
+ttl = 86400;
 offset += 4;
 /* Get the rdlength of the SOA record */
 rdlength = js_readuint16(server_reply,offset);
@@ -2019,8 +2023,8 @@
problems that Franky reported */
 if(ttl  20)
 ttl = 20;
-if(ttl  63072000) /* Two years */
-ttl = 63072000;
+if(ttl  86400) /* One day; Ghost domain fix */
+ttl = 86400;
 /* If this is a CNAME answer then we don't store it for over
  * 15 minutes */
 if(ttl  900  cname_original_record != 0)

On Thu, Jan 17, 2013 at 3:42 AM, Jonathan Wiltshire j...@debian.org wrote:
 Package: maradns

 Dear maintainer,

 Recently you fixed one or more security problems and as a result you closed
 this bug. These problems were not serious enough for a Debian Security
 Advisory, so they are now on my radar for fixing in the following suites
 through point releases:

 squeeze (6.0.7) - use target stable

 Please prepare a minimal-changes upload targetting each of these suites,
 and submit a debdiff to the Release Team [0] for consideration. They will
 offer additional guidance or instruct you to upload your package.

 I will happily assist you at any stage if the patch is straightforward and
 you need help. Please keep me in CC at all times so I can
 track [1] the progress of this request.

 For details of this process and the rationale, please see the original
 announcement [2] and my blog post [3].

 0: debian-rele...@lists.debian.org
 1: http://prsc.debian.net/tracker/665012/
 2: 201101232332.11736.th...@debian.org
 3: http://deb.li/prsc

 Thanks,

 with his security hat on:
 --
 Jonathan Wiltshire  j...@debian.org
 Debian Developer http://people.debian.org/~jmw

 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#665012: CVE-2012-1570: maradns deleted domain record cache persistance flaw

[Sam Trenholme]

Upstream here:

Here are the affected versions of MaraDNS:

All MaraDNS 0 releases (Do NOT use; not maintained)
All MaraDNS 1.0 releases (Do NOT use; not maintained)
All MaraDNS 1.1 releases (Do NOT use; not maintained)
All MaraDNS 1.2 releases (Do NOT use; not maintained)
All MaraDNS 1.3 releases besides 1.3.07 (Do NOT use; not maintained)
All MaraDNS 1.3.07 releases before MaraDNS 1.3.07.15
All MaraDNS 1.4 releases before MaraDNS 1.4.12
All MaraDNS 2 releases before MaraDNS 2.0.06
All Deadwood 3 (subpackage of MaraDNS) releases before Deadwood 3.2.02
All Deadwood 2 releases besides 2.3 (Do NOT use; not maintained)
All Deadwood 2.3 releases before Deadwood 2.3.08

MaraDNS 1.3.07.15, 1.4.12, 2.0.06, as well as Deadwood 3.2.02 and
2.3.08 have been released to address this security bug.  It is
important that all MaraDNS users update to one of these versions.

Also: MaraDNS 1.3.07 will no longer be supported on December 21, 2012.
 Please upgrade to MaraDNS 1.4 or 2.0 at your soonest convenience if
feasible.  Here is an update guide:

http://maradns.org/tutorial/update.html

Distributions and users who wish to continue, against my wishes,
supporting an outdated version of MaraDNS 1 may (or may not) be able
to update MaraDNS 1 by using this patch:

http://maradns.org/download/patches/security/maradns-1.4.11-ghostdomain.patch

- Sam

On Thu, Mar 22, 2012 at 6:28 AM, Giuseppe Iuculano iucul...@debian.org wrote:
 Package: maradns
 Severity: serious
 Tags: security

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 It was reported that MaraDNS suffers from a flaw where it is susceptible to
 spoofing attacks.  Due to an error in the cache update policy, which
 does not properly handle revoked domain names, a remote attacker could keep a
 domain name resolvable after it has been deleted from the registration.

 This flaw is fixed in versions 1.3.0.7.15 and 1.4.12, and is reported to
 affect all prior versions.

 References:

 http://www.maradns.org/changelog.html
 https://secunia.com/advisories/48492/
 https://bugzilla.redhat.com/show_bug.cgi?id=804770


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iEYEARECAAYFAk9q/sIACgkQNxpp46476arqDQCfSFeWlawN7py9L5lKIE+xR1ix
 ATIAn0DxeHe7ugtuET2C9uHbJcAkIwkz
 =Pu/Y
 -END PGP SIGNATURE-






--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org