Debian Patches

Status for djbdns/1:1.05-15

Patch Description Author Forwarded Bugs Origin Last update
0001-hier.c-don-t-install-etc-dnsroots.global.diff hier.c: don't install /etc/dnsroots.global dnsroots.global is installed by debian/rules into debian/djbdns/etc/
instead while building the Debian package.

diff --git a/hier.c b/hier.c
index 4aef75b..b57dba0 100644
Gerrit Pape <pape@smarden.org> no 2020-07-26
0002-djbdns-misformats-some-long-response-packets-patch-a.diff djbdns misformats some long response packets The DNS protocol restricts name compression to point into the first
16384 bytes of a packet. Line 18 of response.c from djbdns 1.05
directly references this, but response_addname() in the same file does
not enforce this at all. The consequence of this is that names in
very large DNS packets may be mangled, and clients may misparse the
packet.
.
Because this email is somewhat long, I'll state up front you can find
a patch for this issue at the bottom of this email or at:
http://shinobi.dempsky.org/~matthew/djbdns-bug/patch
.
To help demonstrate this bug, I've constructed an example attack. In
this scenario, there's a .foo TLD operated using tinydns and axfrdns
(to support DNS queries over TCP; AXFR support is not required). The
attacker has registered x.foo and is allowed to upload NS records for
x.foo and A records for names within the x.foo domain. However,
because of the aforementioned bug, this attacker can construct a
record set that causes the .foo servers to respond to queries asking
about names within the x.foo domain with poisonous records for names
outside of x.foo.
.
Using tinydns-data and tinydns-get from stock djbdns 1.05, you can
reproduce this as follows:
.
$ curl -O http://shinobi.dempsky.org/~matthew/djbdns-bug/data
$ grep -c -v -e '&x\.foo::' -e '^+[^:]*\.x\.foo:' data
0
$ tinydns-data
$ tinydns-get a www.x.foo | grep ': foo '
additional: foo 8388608 NS a.ns.bar
additional: foo 8388608 NS b.ns.bar
.
(With the patch I linked above, no records outside of x.foo will be
served. It's also worth noting the printpacket_cat() routine
tinydns-get uses for pretty printing the response packet is much
stricter about parsing than dnscache's parser is; e.g., it rejects
packets with extra trailing bytes and records with bad rdlength fields
on known record types.)
.
If a victim using dnscache now makes an A query for www.x.foo,
dnscache will save the poisoned records, and begin contacting the
attacker's nameservers for all .foo requests. (The response will be
over 512 bytes long, so dnscache will have to retry the query over
TCP, which is why axfrdns is necessary too.)
.
Now, admittedly if you peek at data, you'll see the supplied records
exceed what most TLDs probably allow: there are redundant NS records,
there are very long names (but still within the allowed limits of the
DNS protocol), names use non-printable characters, there are over 100
records totalling about 24K of storage. However, neither the djbdns
documentation nor standard practice warn potential .foo administrators
that their domain will be at risk for poisoning if they were to add
support for glue record sets. (Standard practice only warns that such
absurd records can negatively impact x.foo, not .foo as well.)
.
A perhaps more reasonable scenario is that the .foo servers fetch the
contents of the x.foo domain over AXFR (removing any records from
outside of x.foo) and then serve the records themselves. axfr-get,
the AXFR client from djbdns, would handle the above data set fine.
.
In looking for a real life example of this latter scenario, I found
freedns.afraid.org. They allowed me to register burlap.afraid.org and
set it up as an AXFR slave to my personal server. I have not explored
what limits they place on imported records, and their website states
they're using BIND, but assuming they're not too limiting and were to
instead use tinydns/axfrdns/axfr-get, it would be possible for me to
trick any dnscache that queries for www.burlap.afraid.org into
contacting another set of nameservers for all of afraid.org's DNS
traffic.
.
There's a similar service everydns.net. They do claim to use tinydns
(and so I assume axfrdns and axfr-get) and also provide AXFR slave
support, but they did not allow me to register burlap.everydns.net.
If they did, it would probably be possible to similarly poison
everydns.net.
.
I've tried to search for previous reports of this issue more
thoroughly than the last bug I mentioned to the list, and I haven't
found any mention of it yet. I emailed Dan earlier today when I first
began to suspect this bug was 'exploitable' to clarify his definition
of a 'security hole' in djbdns. I think the afraid.org example is a
reasonable use case where this bug would violate afraid.org's security
constraints if they were to instead use djbdns.
.
Any thoughts from the list on this bug? (Except from Dean Anderson;
I'm sure he'll spend the next 3 weeks now arguing I'm a blackhat
hacker while refusing to look at the patch or sample data file because
my web server might hack his computer.)

diff --git a/response.c b/response.c
index ba90c89..33b2fb1 100644
Matthew Dempsky <matthew@dempsky.org> no 2020-07-26
0003-dnstracesort.sh-don-t-use-deprecated-number-sort.diff dnstracesort.sh: don't use deprecated "+number" sort(1) option dnstracesort contained the line "sort -t: +0 -2 +4 +3 -4 +2 -3" which
uses the deprecated sort field selection. This commit changes the
options to "-k": "sort -t: -k 1,3 -k 5 -k 4,5 -k 3,4".

diff --git a/dnstracesort.sh b/dnstracesort.sh
index e57359c..108ef2f 100644
Shai Rosenfeld <shaiguitar@gmail.com> no 2020-07-26
0004-tinydns-data-SRV-axfr-get-SRV-PTR-patches.patch tinydns-data SRV & axfr-get SRV/PTR patches Here's a combined patch that:
.
a) adds a native SRV type to tinydns-data
.
Sfqdn:ip:x:port:weight:priority:ttl:timestamp
.
Standard rules for ip, x, ttl, and timestamp apply. Port, weight, and
priority all range from 0-65535. Weight and priority are optional; they
default to zero if not provided.
.
Sconsole.zoinks.example.com:1.2.3.4:rack102-con1:2001:69:7:300:
.
b) makes axfr-get decompose SRV and PTR records and write them out in
native format, rather than opaque. Again, this is necessary because if the
DNAME fields in the records reference the same zone as fqdn, they can have
compression pointers that are bogus outside the context of that specific
packet, and which can't be correctly loaded into data.cdb by tinydns-data.
.
--michael
.
Laurent G. Bercot <ska-djbdns@skarnet.org> updated it for
djbdns-1.05. Documentation patch by Alex Efros.

diff --git a/axfr-get.c b/axfr-get.c
index 75db627..a5d5c0c 100644
Michael Handler <handler@sub-rosa.com> no 2020-07-26
0005-query.c-increase-recursion-depth-to-200.patch query.c: increase recursion depth to 200. The recursion loop for CNAME resolution has an upper limit of 100
iterations by default. This has proven too small in some cases where
large CDNs are concerned. This commit increases the limit to 200.
.
The patch was based on the OpenWrt fix, supplied by user ylxu.

diff --git a/query.c b/query.c
index 46cdc00..61fe708 100644
Michael Orlitzky <michael@orlitzky.com> no 2020-07-26
0006-Fix-ghost-domain-attack-vulnerability-CVE-2012-1191.patch Fix ghost domain attack vulnerability (CVE-2012-1191)
diff --git a/query.c b/query.c
index 61fe708..085cf44 100644
Peter Conrad <conrad@tivano.de> no http://marc.info/?l=djbdns&m=134269902121506&w=2 2020-07-26
0007-dnscache-merge-similar-outgoing-udp-packets.patch dnscache: merge similar outgoing udp packets This patch takes a slightly different approach to merging
than the previous qmerge patch: rather than merging between
the "query" and "dns_transmit" layers, it actually
incorporates the merging into the dns_transmit layer.
.
This makes it a much more invasive and messy patch, but
means that it should correctly handle all situations
(in particular, ones where sending to two different IPs will
gives different results, generally because one server is
down or lame).
.
The general strategy is this:
.
- when a dns_transmit is about to send() a UDP query, it
checks for an equivalent inprogress query.
.
If it finds one, it marks the inprogress dns_transmit as
its "master", and itself as a "slave" of the master.
.
If it doesn't, it sends the packet and registers itself
as inprogress.
.
- when a dns_transmit recv()s a UDP packet, it creates a
copy of the packet for each of its slaves
.
Two outgoing packets are considered equivalent if:
.
1. they are going to the same IP
2. they have the same qtype
3. they have the same qname
.
Because this change affects the dns library itself, this
change can potentially affect not just dnscache, but all of
the diagnostic tools. To address this, merging must be
enabled explicitly by the caller; dnscache will enable
merging if the MERGEQUERIES environment variable is set.
.
I tried to keep the patch as small and simple as possible so
that its correctness could be verified by readers. There
are a few places where performance might benefit from making
it more complex:
.
- dns_transmit now knows the value of MAXUDP, since it is
an upper bound on the number of slaves and inprogress
queries. As a result:
.
- each non-merging program which uses the dns library
wastes MAXUDP*sizeof(pointer) bytes of static memory
for the inprogress list
.
- each dns_transmit uses an extra MAXUDP*sizeof(pointer)
bytes for its slaves list. For dnscache, this
translates to 160K total on a 32-bit platform with
default MAXUDP.
.
Both could be avoided by using dynamic allocation.
.
- We have to do an O(MAXUDP) linear search to find similar
inprogress queries (non-merge-enabled users of the
library avoid paying this price, though).
.
This could be avoided by using a data structure with a
fast key lookup for inprogress.
.
This patch is only lightly tested. Use on production servers at your own
risk (and please report to the list if you have success using it).

diff --git a/clients.h b/clients.h
new file mode 100644
index 0000000..983a4ad
Jeff King <peff () peff ! net> no 2020-07-26
0008-Cache-SOA-records.patch Cache SOA records For more information, how this patch helps to mitigate poisoning attack,
see http://www.your.org/dnscache.

diff --git a/query.c b/query.c
index 085cf44..372d0a6 100644
Jeff King <peff@peff.net> no 2020-07-26
0009-usr-sbin.patch Teach the *-conf tools about /usr/sbin. In the Debian djbdns binary packages, some programs and tools are
located in the /usr/sbin directory, not in /usr/bin.
Peter Pentchev <roam@ringlet.net> not-needed 2020-07-26
0010-dnsroots.global.patch Update the list of root nameservers. Andrew Richards <ar-debianbugs@nwdb.co.uk> no debian 2021-11-13
0011-datalimit.patch Raise the axfrdns, dnscache, and tinydns data limit. Peter Pentchev <roam@ringlet.net> no debian 2021-11-13

All known versions for source package 'djbdns'

Links