1/4/14
`
`vwmietf.org/rfc/rfc1535.t>d
`
`Network Working Group
`Request for Comments: 1535
`Category:
`Informational
`
`E. Gavron
`ACES Research Inc.
`October 1993
`
`A Security Problem and Proposed Correction
`With Widely Deployed DNS Software
`
`Status of this Memo
`
`It does
`This memo provides information for the Internet community.
`not specify an Internet standard. Distribution of this memo is
`uniimited.
`
`
`
`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).
`r“his 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 BIN) 4.9.2 release.
`
`Example: A TELNET attempt by
`to
`
`UnivHost.University.3DU
`
`UserGMachine.Tech.ACES.COM
`
`WMN.ietf.org/rfc/rfc1535.b<t
`
`1/5
`
`Petitioner Apple Inc. - Ex. 1019, p. 1
`
`Petitioner Apple Inc. - Ex. 1019, p. 1
`
`

`

`1/4/14
`
`Gavron
`
`RFC 1535
`
`vuM/v.ietf.org/rfclrfc1535.t>¢
`
`
`DNS Software Enhancements
`
`October 1993
`
`[Page 1]
`
`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
`J.
`unliberal application of one wildcard CNAME record would cause *all*
`
`connects from any .COM site to any .EDU si:e 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
`
`
`
`”he 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.
`
`
`
`
`
`\ANMN.ietf.org/rfc/rfc1535.bd
`
`ZS
`
`Petitioner Apple Inc. - Ex. 1019, p. 2
`
`.com sites would end up at
`”hus all connects to Harvard.edu from all
`targthost, a machine wqich could provide a Harvard.edu login banner.
`_‘
`
`"his is cieariy unacceptable. Further, it could only be made worse
`
`
`with doma'ns ‘ike COM.EDU, MIL.GOV, GOV.COM, etc.
`
`
`
`Pub"c vs. Local Name Space Administration
`
`
`
`Petitioner Apple Inc. - Ex. 1019, p. 2
`
`

`

`1/4/14
`
`Gavron
`
`vuM/v.ietf.org/rfclrfc1535.t>¢
`
`[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
`
`:he error impacts users outside of a local administration.
`
`
`
`When attempting to resolve a partial domain name, DNS resolvers use
`:he 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.DmSnRTU.nDU,
`
`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
`
`the value of "search" should be set to "DESERTU.EDU"
`In this case,
`because that's the scope of the name space controlled by the local
`DNS administrator.
`
`The local administrator
`This is more than a mere optimization hack.
`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
`
`\ANMN.ietf.org/rfc/rfc1535.bd
`
`[Page 3]
`
`3/5
`
`Petitioner Apple Inc. - Ex. 1019, p. 3
`
`Petitioner Apple Inc. - Ex. 1019, p. 3
`
`

`

`1/4/14
`
`vuM/v.ietf.org/rfclrfc1535.t>¢
`
`RFC 1535
`
`
`DNS Software Enhancements
`
`October 1993
`
`A more stringent mechanism is implemented in BIND 4.9.2,
`to this problem:
`
`to respond
`
`
`
`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 :o 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.
`
`in any event Where a "." exists in a specified name it
`Further,
`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.locl.org.city.state.us
`might be used to making references to bar.locZ, 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
`
`\ANMN.ietf.org/rfc/rfc1535.bd
`
`[Page 4]
`
`4/5
`
`Petitioner Apple Inc. - Ex. 1019, p. 4
`
`Petitioner Apple Inc. - Ex. 1019, p. 4
`
`

`

`1/4/14
`RFC 1535
`
`vuM/v.ietf.org/rfclrfc1535.t>¢
`
`DNS Software Enhancements
`
`October 1993
`
`References
`
`"Domain Names Concepts and Facilities", STD 13,
`[1] Mockapetris, P.,
`RFC 1034, USC/Information Sciences Institute, November 1987.
`
`"Domain Names Implementation and Specification",
`[2] Mockapetris, P.,
`STD 13, RFC 1035, USC/Information Sciences Institute, November
`1987.
`
`"Mail Routing and the Domain System", STD 14, RFC
`[3] Partridge, C.,
`
`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.
`
`"Common DNS Data File Configuration Errors", RFC
`[5] Beertema, P.,
`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
`
`(602) 743-9841
`Phone:
`EMail: gavron@aces.com
`
`Gavron
`
`\ANMN.ietf.org/rfc/rfc1535.bd
`
`[Page 5]
`
`5/5
`
`Petitioner Apple Inc. - Ex. 1019, p. 5
`
`Petitioner Apple Inc. - Ex. 1019, p. 5
`
`