contrib/bind9/doc/rfc/rfc1535.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          E. Gavron
   8 Request for Comments: 1535                            ACES Research Inc.
   9 Category: Informational                                     October 1993
  10
  11
  12               A Security Problem and Proposed Correction
  13                    With Widely Deployed DNS Software
  14
  15 Status of this Memo
  16
  17    This memo provides information for the Internet community.  It does
  18    not specify an Internet standard.  Distribution of this memo is
  19    unlimited.
  20
  21 Abstract
  22
  23    This document discusses a flaw in some of the currently distributed
  24    name resolver clients.  The flaw exposes a security weakness related
  25    to the search heuristic invoked by these same resolvers when users
  26    provide a partial domain name, and which is easy to exploit (although
  27    not by the masses).  This document points out the flaw, a case in
  28    point, and a solution.
  29
  30 Background
  31
  32    Current Domain Name Server clients are designed to ease the burden of
  33    remembering IP dotted quad addresses.  As such they translate human-
  34    readable names into addresses and other resource records.  Part of
  35    the translation process includes understanding and dealing with
  36    hostnames that are not fully qualified domain names (FQDNs).
  37
  38    An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
  39    domain name is of the format {name}
  40
  41    A domain name may have many parts and typically these include the
  42    host, domain, and type.  Example:  foobar.company.com or
  43    fooschool.university.edu.
  44
  45 Flaw
  46
  47    The problem with most widely distributed resolvers based on the BSD
  48    BIND resolver is that they attempt to resolve a partial name by
  49    processing a search list of partial domains to be added to portions
  50    of the specified host name until a DNS record is found.  This
  51    "feature" is disabled by default in the official BIND 4.9.2 release.
  52
  53    Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
  54                              to    UnivHost.University.EDU
  55
  56
  57
  58 Gavron                                                          [Page 1]
  59 \f
  60 RFC 1535               DNS Software Enhancements            October 1993
  61
  62
  63    The resolver client will realize that since "UnivHost.University.EDU"
  64    does not end with a ".", it is not an absolute "rooted" FQDN.  It
  65    will then try the following combinations until a resource record is
  66    found:
  67
  68                 UnivHost.University.EDU.Tech.ACES.COM.
  69                 UnivHost.University.EDU.ACES.COM.
  70                 UnivHost.University.EDU.COM.
  71                 UnivHost.University.EDU.
  72
  73 Security Issue
  74
  75    After registering the EDU.COM domain, it was discovered that an
  76    unliberal application of one wildcard CNAME record would cause *all*
  77    connects from any .COM site to any .EDU site to terminate at one
  78    target machine in the private edu.com sub-domain.
  79
  80    Further, discussion reveals that specific hostnames registered in
  81    this private subdomain, or any similarly named subdomain may be used
  82    to spoof a host.
  83
  84         Example:        harvard.edu.com.        CNAME   targethost
  85
  86    Thus all connects to Harvard.edu from all .com sites would end up at
  87    targthost, a machine which could provide a Harvard.edu login banner.
  88
  89    This is clearly unacceptable.  Further, it could only be made worse
  90    with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
  91
  92 Public vs. Local Name Space Administration
  93
  94    The specification of the Domain Name System and the software that
  95    implements it provides an undifferentiated hierarchy which permits
  96    delegation of administration for subordinate portions of the name
  97    space.  Actual administration of the name space is divided between
  98    "public" and "local" portions.  Public administration pertains to all
  99    top-level domains, such as .COM and .EDU.  For some domains, it also
 100    pertains to some number of sub-domain levels.  The multi-level nature
 101    of the public administration is most evident for top-level domains
 102    for countries.  For example in the Fully Qualified Domain Name,
 103    dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
 104    of public administration.  Only the left-most portion is subject to
 105    local administration.
 106
 107
 108
 109
 110
 111
 112
 113
 114 Gavron                                                          [Page 2]
 115 \f
 116 RFC 1535               DNS Software Enhancements            October 1993
 117
 118
 119    The danger of the heuristic search common in current practise is that
 120    it it is possible to "intercept" the search by matching against an
 121    unintended value while walking up the search list.  While this is
 122    potentially dangerous at any level, it is entirely unacceptable when
 123    the error impacts users outside of a local administration.
 124
 125    When attempting to resolve a partial domain name, DNS resolvers use
 126    the Domain Name of the searching host for deriving the search list.
 127    Existing DNS resolvers do not distinguish the portion of that name
 128    which is in the locally administered scope from the part that is
 129    publically administered.
 130
 131 Solution(s)
 132
 133    At a minimum, DNS resolvers must honor the BOUNDARY between local and
 134    public administration, by limiting any search lists to locally-
 135    administered portions of the Domain Name space.  This requires a
 136    parameter which shows the scope of the name space controlled by the
 137    local administrator.
 138
 139    This would permit progressive searches from the most qualified to
 140    less qualified up through the locally controlled domain, but not
 141    beyond.
 142
 143    For example, if the local user were trying to reach:
 144
 145         User@chief.admin.DESERTU.EDU from
 146         starburst,astro.DESERTU.EDU,
 147
 148    it is reasonable to permit the user to enter just chief.admin, and
 149    for the search to cover:
 150
 151         chief.admin.astro.DESERTU.EDU
 152         chief.admin.DESERTU.EDU
 153
 154    but not
 155
 156         chief.admin.EDU
 157
 158    In this case, the value of "search" should be set to "DESERTU.EDU"
 159    because that's the scope of the name space controlled by the local
 160    DNS administrator.
 161
 162    This is more than a mere optimization hack.  The local administrator
 163    has control over the assignment of names within the locally
 164    administered domain, so the administrator can make sure that
 165    abbreviations result in the right thing.  Outside of the local
 166    control, users are necessarily at risk.
 167
 168
 169
 170 Gavron                                                          [Page 3]
 171 \f
 172 RFC 1535               DNS Software Enhancements            October 1993
 173
 174
 175    A more stringent mechanism is implemented in BIND 4.9.2, to respond
 176    to this problem:
 177
 178    The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
 179    to only try the first and the last of the examples shown.
 180
 181    Any additional search alternatives must be configured into the
 182    resolver EXPLICITLY.
 183
 184    DNS Name resolver software SHOULD NOT use implicit search lists in
 185    attempts to resolve partial names into absolute FQDNs other than the
 186    hosts's immediate parent domain.
 187
 188    Resolvers which continue to use implicit search lists MUST limit
 189    their scope to locally administered sub-domains.
 190
 191    DNS Name resolver software SHOULD NOT come pre-configured with
 192    explicit search lists that perpetuate this problem.
 193
 194    Further, in any event where a "." exists in a specified name it
 195    should be assumed to be a fully qualified domain name (FQDN) and
 196    SHOULD be tried as a rooted name first.
 197
 198    Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
 199              should be attempted as a result of using an implicit
 200              search list:
 201
 202                 e.f.g.h.  and e.f.g.h.b.c.d.
 203
 204              Given user@a.b.c.d. connecting to host those same two
 205              tries would appear as:
 206
 207                 x.b.c.d.  and x.
 208
 209    Some organizations make regular use of multi-part, partially
 210    qualified Domain Names.  For example, host foo.loc1.org.city.state.us
 211    might be used to making references to bar.loc2, or mumble.loc3, all
 212    of which refer to whatever.locN.org.city.state.us
 213
 214    The stringent implicit search rules for BIND 4.9.2 will now cause
 215    these searches to fail.  To return the ability for them to succeed,
 216    configuration of the client resolvers must be changed to include an
 217    explicit search rule for org.city.state.us.  That is, it must contain
 218    an explicit rule for any -- and each -- portion of the locally-
 219    administered sub-domain that it wishes to have as part of the search
 220    list.
 221
 222
 223
 224
 225
 226 Gavron                                                          [Page 4]
 227 \f
 228 RFC 1535               DNS Software Enhancements            October 1993
 229
 230
 231 References
 232
 233    [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
 234        RFC 1034, USC/Information Sciences Institute, November 1987.
 235
 236    [2] Mockapetris, P., "Domain Names Implementation and Specification",
 237        STD 13, RFC 1035, USC/Information Sciences Institute, November
 238        1987.
 239
 240    [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
 241        974, CSNET CIC BBN, January 1986.
 242
 243    [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
 244        "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
 245        USC/Information Sciences Institute, USC, October 1993.
 246
 247    [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
 248        1537, CWI, October 1993.
 249
 250 Security Considerations
 251
 252    This memo indicates vulnerabilities with all too-forgiving DNS
 253    clients.  It points out a correction that would eliminate the future
 254    potential of the problem.
 255
 256 Author's Address
 257
 258    Ehud Gavron
 259    ACES Research Inc.
 260    PO Box 14546
 261    Tucson, AZ 85711
 262
 263    Phone: (602) 743-9841
 264    EMail: gavron@aces.com
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Gavron                                                          [Page 5]
 283 \f