Browse Prior Art Database

A Security Problem and Proposed Correction With Widely Deployed DNS Software (RFC1535)

IP.com Disclosure Number: IPCOM000002366D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 4 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Gavron: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 33% of the total text.

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

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.

Th...