284 lines
9.5 KiB
Plaintext
284 lines
9.5 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group E. Gavron
|
||
Request for Comments: 1535 ACES Research Inc.
|
||
Category: Informational October 1993
|
||
|
||
|
||
A Security Problem and Proposed Correction
|
||
With Widely Deployed DNS Software
|
||
|
||
Status of this Memo
|
||
|
||
This memo provides information for the Internet community. It does
|
||
not specify an Internet standard. Distribution of this memo is
|
||
unlimited.
|
||
|
||
Abstract
|
||
|
||
This document discusses a flaw in some of the currently distributed
|
||
name resolver clients. The flaw exposes a security weakness related
|
||
to the search heuristic invoked by these same resolvers when users
|
||
provide a partial domain name, and which is easy to exploit (although
|
||
not by the masses). This document points out the flaw, a case in
|
||
point, and a solution.
|
||
|
||
Background
|
||
|
||
Current Domain Name Server clients are designed to ease the burden of
|
||
remembering IP dotted quad addresses. As such they translate human-
|
||
readable names into addresses and other resource records. Part of
|
||
the translation process includes understanding and dealing with
|
||
hostnames that are not fully qualified domain names (FQDNs).
|
||
|
||
An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
|
||
domain name is of the format {name}
|
||
|
||
A domain name may have many parts and typically these include the
|
||
host, domain, and type. Example: foobar.company.com or
|
||
fooschool.university.edu.
|
||
|
||
Flaw
|
||
|
||
The problem with most widely distributed resolvers based on the BSD
|
||
BIND resolver is that they attempt to resolve a partial name by
|
||
processing a search list of partial domains to be added to portions
|
||
of the specified host name until a DNS record is found. This
|
||
"feature" is disabled by default in the official BIND 4.9.2 release.
|
||
|
||
Example: A TELNET attempt by User@Machine.Tech.ACES.COM
|
||
to UnivHost.University.EDU
|
||
|
||
|
||
|
||
Gavron [Page 1]
|
||
|
||
RFC 1535 DNS Software Enhancements October 1993
|
||
|
||
|
||
The resolver client will realize that since "UnivHost.University.EDU"
|
||
does not end with a ".", it is not an absolute "rooted" FQDN. It
|
||
will then try the following combinations until a resource record is
|
||
found:
|
||
|
||
UnivHost.University.EDU.Tech.ACES.COM.
|
||
UnivHost.University.EDU.ACES.COM.
|
||
UnivHost.University.EDU.COM.
|
||
UnivHost.University.EDU.
|
||
|
||
Security Issue
|
||
|
||
After registering the EDU.COM domain, it was discovered that an
|
||
unliberal application of one wildcard CNAME record would cause *all*
|
||
connects from any .COM site to any .EDU site to terminate at one
|
||
target machine in the private edu.com sub-domain.
|
||
|
||
Further, discussion reveals that specific hostnames registered in
|
||
this private subdomain, or any similarly named subdomain may be used
|
||
to spoof a host.
|
||
|
||
Example: harvard.edu.com. CNAME targethost
|
||
|
||
Thus all connects to Harvard.edu from all .com sites would end up at
|
||
targthost, a machine which could provide a Harvard.edu login banner.
|
||
|
||
This is clearly unacceptable. Further, it could only be made worse
|
||
with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
|
||
|
||
Public vs. Local Name Space Administration
|
||
|
||
The specification of the Domain Name System and the software that
|
||
implements it provides an undifferentiated hierarchy which permits
|
||
delegation of administration for subordinate portions of the name
|
||
space. Actual administration of the name space is divided between
|
||
"public" and "local" portions. Public administration pertains to all
|
||
top-level domains, such as .COM and .EDU. For some domains, it also
|
||
pertains to some number of sub-domain levels. The multi-level nature
|
||
of the public administration is most evident for top-level domains
|
||
for countries. For example in the Fully Qualified Domain Name,
|
||
dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
|
||
of public administration. Only the left-most portion is subject to
|
||
local administration.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gavron [Page 2]
|
||
|
||
RFC 1535 DNS Software Enhancements October 1993
|
||
|
||
|
||
The danger of the heuristic search common in current practise is that
|
||
it it is possible to "intercept" the search by matching against an
|
||
unintended value while walking up the search list. While this is
|
||
potentially dangerous at any level, it is entirely unacceptable when
|
||
the error impacts users outside of a local administration.
|
||
|
||
When attempting to resolve a partial domain name, DNS resolvers use
|
||
the Domain Name of the searching host for deriving the search list.
|
||
Existing DNS resolvers do not distinguish the portion of that name
|
||
which is in the locally administered scope from the part that is
|
||
publically administered.
|
||
|
||
Solution(s)
|
||
|
||
At a minimum, DNS resolvers must honor the BOUNDARY between local and
|
||
public administration, by limiting any search lists to locally-
|
||
administered portions of the Domain Name space. This requires a
|
||
parameter which shows the scope of the name space controlled by the
|
||
local administrator.
|
||
|
||
This would permit progressive searches from the most qualified to
|
||
less qualified up through the locally controlled domain, but not
|
||
beyond.
|
||
|
||
For example, if the local user were trying to reach:
|
||
|
||
User@chief.admin.DESERTU.EDU from
|
||
starburst,astro.DESERTU.EDU,
|
||
|
||
it is reasonable to permit the user to enter just chief.admin, and
|
||
for the search to cover:
|
||
|
||
chief.admin.astro.DESERTU.EDU
|
||
chief.admin.DESERTU.EDU
|
||
|
||
but not
|
||
|
||
chief.admin.EDU
|
||
|
||
In this case, the value of "search" should be set to "DESERTU.EDU"
|
||
because that's the scope of the name space controlled by the local
|
||
DNS administrator.
|
||
|
||
This is more than a mere optimization hack. The local administrator
|
||
has control over the assignment of names within the locally
|
||
administered domain, so the administrator can make sure that
|
||
abbreviations result in the right thing. Outside of the local
|
||
control, users are necessarily at risk.
|
||
|
||
|
||
|
||
Gavron [Page 3]
|
||
|
||
RFC 1535 DNS Software Enhancements October 1993
|
||
|
||
|
||
A more stringent mechanism is implemented in BIND 4.9.2, to respond
|
||
to this problem:
|
||
|
||
The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
|
||
to only try the first and the last of the examples shown.
|
||
|
||
Any additional search alternatives must be configured into the
|
||
resolver EXPLICITLY.
|
||
|
||
DNS Name resolver software SHOULD NOT use implicit search lists in
|
||
attempts to resolve partial names into absolute FQDNs other than the
|
||
hosts's immediate parent domain.
|
||
|
||
Resolvers which continue to use implicit search lists MUST limit
|
||
their scope to locally administered sub-domains.
|
||
|
||
DNS Name resolver software SHOULD NOT come pre-configured with
|
||
explicit search lists that perpetuate this problem.
|
||
|
||
Further, in any event where a "." exists in a specified name it
|
||
should be assumed to be a fully qualified domain name (FQDN) and
|
||
SHOULD be tried as a rooted name first.
|
||
|
||
Example: Given user@a.b.c.d connecting to e.f.g.h only two tries
|
||
should be attempted as a result of using an implicit
|
||
search list:
|
||
|
||
e.f.g.h. and e.f.g.h.b.c.d.
|
||
|
||
Given user@a.b.c.d. connecting to host those same two
|
||
tries would appear as:
|
||
|
||
x.b.c.d. and x.
|
||
|
||
Some organizations make regular use of multi-part, partially
|
||
qualified Domain Names. For example, host foo.loc1.org.city.state.us
|
||
might be used to making references to bar.loc2, or mumble.loc3, all
|
||
of which refer to whatever.locN.org.city.state.us
|
||
|
||
The stringent implicit search rules for BIND 4.9.2 will now cause
|
||
these searches to fail. To return the ability for them to succeed,
|
||
configuration of the client resolvers must be changed to include an
|
||
explicit search rule for org.city.state.us. That is, it must contain
|
||
an explicit rule for any -- and each -- portion of the locally-
|
||
administered sub-domain that it wishes to have as part of the search
|
||
list.
|
||
|
||
|
||
|
||
|
||
|
||
Gavron [Page 4]
|
||
|
||
RFC 1535 DNS Software Enhancements October 1993
|
||
|
||
|
||
References
|
||
|
||
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
|
||
RFC 1034, USC/Information Sciences Institute, November 1987.
|
||
|
||
[2] Mockapetris, P., "Domain Names Implementation and Specification",
|
||
STD 13, RFC 1035, USC/Information Sciences Institute, November
|
||
1987.
|
||
|
||
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
|
||
974, CSNET CIC BBN, January 1986.
|
||
|
||
[4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
|
||
"Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
|
||
USC/Information Sciences Institute, USC, October 1993.
|
||
|
||
[5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
|
||
1537, CWI, October 1993.
|
||
|
||
Security Considerations
|
||
|
||
This memo indicates vulnerabilities with all too-forgiving DNS
|
||
clients. It points out a correction that would eliminate the future
|
||
potential of the problem.
|
||
|
||
Author's Address
|
||
|
||
Ehud Gavron
|
||
ACES Research Inc.
|
||
PO Box 14546
|
||
Tucson, AZ 85711
|
||
|
||
Phone: (602) 743-9841
|
||
EMail: gavron@aces.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gavron [Page 5]
|
||
|