8677508 2002-07-02 00:33 -0400 /38 rader/ Tim Gladding <tim@gladding.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-02 21:24 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22915>
Ärende: BIND 9.2.1 patch, multiple RR's for singleton types.
------------------------------------------------------------
From: Tim Gladding <tim@gladding.com>
To: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33L2.0207012310170.3589-200000@xena.spodnet.org>
With the release of the libbind buffer overflow a number of people
have suggested loading a copy of BIND locally and pointing your local
resolver at just that name server, providing a sanity check of all
incoming DNS traffic. For the most part this will work, however, for
it to work effectively you must be using BIND 9.x because BIND 8.x
does not reconstruct all responses before forwarding them on.
For more information on the libbind buffer overflow bug please see:
http://www.cert.org/advisories/CA-2002-19.html
However, your situation may preclude you from running BIND 9 either
locally or at the site level. One such situation would be that you
are already running BIND 8 and you have zones loaded that will not
load in to BIND 9 because they have multiple resource records
assigned to one singleton data type. For example, an A record
pointing to a list of CNAMES:
fuzzy IN CNAME www.snuggie.com.
IN CNAME www.r-9.net.
Normally BIND 9 would reject this as part of a zone.
To overcome this particular problem I have produced the attached
patch(1) to BIND 9.2.1 which, when applied, will again allow you to
use multiple CNAMEs etc. on one RR. This patch is the equivalent of
the 'multiple-cnames yes;' option in bind 8.x.
WARNING!! Although I am running this patch in a production
environment I cannot guarantee that this patch will work for you.
Please be sure to double check the functionality of this patch before
employing it in any environment!!
--
Tim Gladding
(8677508) /Tim Gladding <tim@gladding.com>/(Ombruten)
Bilaga (text/plain) i text 8677509
Kommentar i text 8678073 av Jim Reid <jim@rfc1035.com>
8677509 2002-07-02 00:33 -0400 /38 rader/ Tim Gladding <tim@gladding.com>
Bilagans filnamn: "rdataslab.c.patch"
Importerad: 2002-07-02 21:24 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22916>
Bilaga (text/plain) till text 8677508
Ärende: Bilaga (rdataslab.c.patch) till: BIND 9.2.1 patch, multiple RR's for singleton types.
------------------------------------------------------------
--- bind-9.2.1/lib/dns/rdataslab.c.orig Tue Jan 9 16:51:25 2001
+++ bind-9.2.1/lib/dns/rdataslab.c Mon Jul 1 22:49:19 2002
@@ -111,14 +111,14 @@
/*
* Ensure that singleton types are actually singletons.
*/
- if (nitems > 1 && dns_rdatatype_issingleton(rdataset->type)) {
+ /* if (nitems > 1 && dns_rdatatype_issingleton(rdataset->type)) { */
/*
* We have a singleton type, but there's more than one
* RR in the rdataset.
*/
- result = DNS_R_SINGLETON;
+ /* result = DNS_R_SINGLETON;
goto free_rdatas;
- }
+ } */
/*
* Allocate the memory, set up a buffer, start copying in
@@ -310,13 +310,13 @@
/*
* Ensure that singleton types are actually singletons.
*/
- if (tcount > 1 && dns_rdatatype_issingleton(type)) {
+ /* if (tcount > 1 && dns_rdatatype_issingleton(type)) { */
/*
* We have a singleton type, but there's more than one
* RR in the rdataset.
*/
- return (DNS_R_SINGLETON);
- }
+ /* return (DNS_R_SINGLETON);
+ } */
/*
* Copy the reserved area from the new slab.
(8677509) /Tim Gladding <tim@gladding.com>/---------
8678073 2002-07-02 20:49 +0100 /59 rader/ Jim Reid <jim@rfc1035.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-03 00:02 av Brevbäraren
Extern mottagare: Tim Gladding <tim@gladding.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22927>
Kommentar till text 8677508 av Tim Gladding <tim@gladding.com>
Ärende: Re: BIND 9.2.1 patch, multiple RR's for singleton types.
------------------------------------------------------------
From: Jim Reid <jim@rfc1035.com>
To: Tim Gladding <tim@gladding.com>
Cc: bugtraq@securityfocus.com
Message-ID: <14589.1025639383@gromit.rfc1035.com>
>>>>> "Tim" == Tim Gladding <tim@gladding.com> writes:
Tim> However, your situation may preclude you from running BIND 9
Tim> either locally or at the site level. One such situation
Tim> would be that you are already running BIND 8 and you have
Tim> zones loaded that will not load in to BIND 9 because they
Tim> have multiple resource records assigned to one singleton data
Tim> type. For example, an A record pointing to a list of CNAMES:
Tim> fuzzy IN CNAME www.snuggie.com.
Tim> IN CNAME www.r-9.net.
Tim> Normally BIND 9 would reject this as part of a zone.
Correct. And that's the way it should be. RFC1034 is very clear that
multiple CNAMEs are illegal. I quote:
If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and
its aliases cannot be different. This rule also insures that
a cached CNAME can be used without checking with an
authoritative server for other RR types.
And before any DNS pedants chime in, this rule has been relaxed in
RFC2181 so that when DNSSEC is in use, a CNAME may have KEY, SIG or
NXT records.
Tim> To overcome this particular problem I have produced the
Tim> attached patch(1) to BIND 9.2.1 which, when applied, will
Tim> again allow you to use multiple CNAMEs etc. on one RR. This
Tim> patch is the equivalent of the 'multiple-cnames yes;' option
Tim> in bind 8.x.
This is a very unwise thing to do and I strongly recommend against
applying this patch. It will cause more problems than it apparently
"solves". Aside from creating a name server that violates RFC1034, the
patch needlessly creates an interoperability and software maintenance
nightmare. What if your slave (secondary) servers reject these illegal
multiple CNAMEs? What happens when the next BIND9 release comes along?
What if somebody else in your organisation installs it and they're
unaware of this special patch? Your patches miss a few things too:
like the code that parses named.conf or the documentation. For BIND9
the documentation does an accurate job of describing the code and it's
not nice to introduce gratuitous discrepancies.
The real solution to the question you pose is to fix the underlying
problem at source (forgive the pun). Get rid of the illegal multiple
CNAMEs. For the example above, just provide two A records for fuzzie
that have the IP addresses of www.snuggie.com and ww.r-9.net. And put
some comments in the zone file and version control logs explaining
what these RRs are for and why they are there. This will save another
maintenance headache for your eventual successor.
(8678073) /Jim Reid <jim@rfc1035.com>/--------------
Kommentar i text 8687624 av der Mouse <mouse@Rodents.Montreal.QC.CA>
Kommentar i text 8689223 av Tim Gladding <tim@gladding.com>
8687624 2002-07-04 09:54 -0400 /31 rader/ der Mouse <mouse@Rodents.Montreal.QC.CA>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-04 21:12 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22957>
Kommentar till text 8678073 av Jim Reid <jim@rfc1035.com>
Ärende: Re: BIND 9.2.1 patch, multiple RR's for singleton types.
------------------------------------------------------------
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
To: bugtraq@securityfocus.com
Message-ID: <200207041354.JAA21105@Sparkle.Rodents.Montreal.QC.CA>
>> fuzzy IN CNAME www.snuggie.com.
>> IN CNAME www.r-9.net.
> The real solution to the question you pose is to fix the underlying
> problem at source (forgive the pun). Get rid of the illegal multiple
> CNAMEs. For the example above, just provide two A records for fuzzie
> that have the IP addresses of www.snuggie.com and ww.r-9.net. And
> put some comments in the zone file and version control logs
> explaining what these RRs are for and why they are there. This will
> save another maintenance headache for your eventual successor.
While creating a maintenance headache whenever www.snuggie.com and/or
www.r-9.net happen to modify the list of addresses they resolve to.
This "solution" creates problems of its own; it is no more a "real
solution" than the other. The only real benefit I can see to it is
that it doesn't involve fixing the underlying lack and thus requires
no effort from the rest of the world, and even that is a benefit only
to that "rest of the world", not to the person you are offering it as
a "solution" to.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
(8687624) /der Mouse <mouse@Rodents.Montreal.QC.CA>/(Ombruten)
8689223 2002-07-03 09:00 -0400 /120 rader/ Tim Gladding <tim@gladding.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-05 08:56 av Brevbäraren
Extern mottagare: Jim Reid <jim@rfc1035.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22960>
Kommentar till text 8678073 av Jim Reid <jim@rfc1035.com>
Ärende: Re: BIND 9.2.1 patch, multiple RR's for singleton types.
------------------------------------------------------------
From: Tim Gladding <tim@gladding.com>
To: Jim Reid <jim@rfc1035.com>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33L2.0207030829510.3589-100000@xena.spodnet.org>
On Tue, 2 Jul 2002, Jim Reid wrote:
> >>>>> "Tim" == Tim Gladding <tim@gladding.com> writes:
>
> Tim> However, your situation may preclude you from running BIND 9
> Tim> either locally or at the site level. One such situation
> Tim> would be that you are already running BIND 8 and you have
> Tim> zones loaded that will not load in to BIND 9 because they
> Tim> have multiple resource records assigned to one singleton data
> Tim> type. For example, an A record pointing to a list of CNAMES:
>
> Tim> fuzzy IN CNAME www.snuggie.com.
> Tim> IN CNAME www.r-9.net.
>
> Tim> Normally BIND 9 would reject this as part of a zone.
>
> Correct. And that's the way it should be. RFC1034 is very clear that
> multiple CNAMEs are illegal.
You're missing the point!
> Tim> To overcome this particular problem I have produced the
> Tim> attached patch(1) to BIND 9.2.1 which, when applied, will
> Tim> again allow you to use multiple CNAMEs etc. on one RR. This
> Tim> patch is the equivalent of the 'multiple-cnames yes;' option
> Tim> in bind 8.x.
>
> This is a very unwise thing to do and I strongly recommend against
> applying this patch. It will cause more problems than it apparently
> "solves". Aside from creating a name server that violates RFC1034, the
> patch needlessly creates an interoperability and software maintenance
> nightmare. What if your slave (secondary) servers reject these illegal
> multiple CNAMEs? What happens when the next BIND9 release comes along?
> What if somebody else in your organisation installs it and they're
> unaware of this special patch? Your patches miss a few things too:
> like the code that parses named.conf or the documentation. For BIND9
> the documentation does an accurate job of describing the code and it's
> not nice to introduce gratuitous discrepancies.
Yeah, all very real and valid points, however, my patch is a quick,
dirty, messy, throw it up now and fix 'em all later solution to the
underlying problem that is multiple vulnerable resolvers living on
your network of which not all will be patched in time for the holiday
weekend because vendors just aren't coming out with the patches fast
enough.
Let's say you have 1,000 hosts of which only about half can be
patched at the moment (remember, you can't just drop BIND 8.3.3's
libbind on every piece of network equipment that does dns
resolution), and 20 name servers currently running BIND 8. You want
to protect those remaining 500 hosts by putting BIND 9 between them
and the world but you can't simply run BIND 9 because you have
possibly hundreds of zone files created by a huge number of people
dating back several years, a number of which break RFC1034, to load.
Sure, you can and SHOULD fix the errors in your zone files but are
you going to be able to complete this task between now and the
holiday weekend.. or are you planning to stay in the office through
Monday? or perhaps you'd rather just leave those 500 hosts exposed
to the world and pray that no-one figures out where you are and that
you are still using a vulnerable resolver?
In short.. yeah I know it breaks RFC1034, yeah I know you should fix
your zone files instead, however, given the choice I'd rather have a
holiday weekend with secure hosts sitting behind my patched BIND 9
servers! It's up to you, and judging by the number of mails I've
received saying 'thanks!' or 'that's great but my mail server blocked
your attachment, please please please send it to me!', the people
agree :)
Which reminds me, because lots of people were not able to receive the
attachment, here is the patch again included.. enjoy!
Tim Gladding
******************************************************************************
--- bind-9.2.1/lib/dns/rdataslab.c.orig Tue Jan 9 16:51:25 2001
+++ bind-9.2.1/lib/dns/rdataslab.c Mon Jul 1 22:49:19 2002
@@ -111,14 +111,14 @@
/*
* Ensure that singleton types are actually singletons.
*/
- if (nitems > 1 && dns_rdatatype_issingleton(rdataset->type)) {
+ /* if (nitems > 1 && dns_rdatatype_issingleton(rdataset->type)) { */
/*
* We have a singleton type, but there's more than one
* RR in the rdataset.
*/
- result = DNS_R_SINGLETON;
+ /* result = DNS_R_SINGLETON;
goto free_rdatas;
- }
+ } */
/*
* Allocate the memory, set up a buffer, start copying in
@@ -310,13 +310,13 @@
/*
* Ensure that singleton types are actually singletons.
*/
- if (tcount > 1 && dns_rdatatype_issingleton(type)) {
+ /* if (tcount > 1 && dns_rdatatype_issingleton(type)) { */
/*
* We have a singleton type, but there's more than one
* RR in the rdataset.
*/
- return (DNS_R_SINGLETON);
- }
+ /* return (DNS_R_SINGLETON);
+ } */
/*
* Copy the reserved area from the new slab.
******************************************************************************
(8689223) /Tim Gladding <tim@gladding.com>/(Ombruten)
Kommentar i text 8691737 av Aaron C. Newman <aaron@newman-family.com>