この文書はRFC1535の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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).
現在のドメインネームサーバのクライアントはＩＰドット区切りアドレスを
覚える負担を減らすように意図されます。これは人が読める名前をアドレス
と他の資源レコードに翻訳します。翻訳プロセスの一部が完全指定されたド
メイン名（FQDN）でないホスト名を理解し、扱うことを含みます。
An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
domain name is of the format {name}
絶対"rooted" FQDNのフォーマットは{name}{.}です。"rooted"でないドメイ
ン名のフォーマットが{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.
ドメイン名が多くの部分を持つかもしれなく、典型的にこれらはホストとド
メインとタイプを含みます。例：foobar.company.comや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.
もっとも広く使われているＢＳＤのＢＩＮＤリゾルバに基づく問題は、それ
らがＤＮＳレコードが見つけるまで指定されたホスト名に加えるドメインの
探索リストを処理して、ホスト名を変換しようと試みるということです。こ
の「機能は」は公式のBIND 4.9.2リリースでデフォルトでは使用不能です。
Example: A TELNET attempt by User@Machine.Tech.ACES.COM
to UnivHost.University.EDU
例：User@Machine.Tech.ACES.COMによる
UnivHost.University.EDUへのTELNETの試み
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"が"."で終わらないと気
づきます、これは"rooted" FQDNでありません。そこで、資源レコードが見つ
かるまで、次の組合せを試みるでしょう：。
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.
EDU.COM ドメインを登録した後で、あるワイルドカードCNAMEレコードの細か
いアプリケーションが、any.COMサイトから any.EDUサイトのプライベートの
edu.comサブドメインの目標マシンで終端することが発見されました。
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.
すべての.comサイトからHarvard.eduまでのすべての接続はtargthostに接続
し、targthostはHarvard.eduログインバナーを供給できるでしょう。
This is clearly unacceptable. Further, it could only be made worse
with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
これは明らかに受け入れ難いです。さらに、COM.EDUやMIL.GOVやGOV.COMのド
メインでもっと困ったことになります。
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.
ドメインネームシステムとそれを実行するソフトウェアの仕様書は名前空間
の従属的な部分の管理委任を認める区別しない階層を提供します。名前空間
の実体は「公共」と「ローカル」に分けられます。公共管理が.comや.EDUな
どの最上位ドメインに関係があります。あるドメインで管理はサブドメイン
レベルに関係があります。多数のレベルの公共の管理は国別最上位ドメイン
で最も明白です。例えば完全に指定したドメイン名dbc.mtview.ca.us.で
"mtview.ca.us"の部分は３レベルの公共の管理を表します。ただ左の部分だ
けがローカル管理の適用を受けています。
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と入力し、捜索が成功するのは合理的です：
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.
この場合、「探索」の値は、ローカルＤＮＳ管理者にコントロールされる名
前空間の範囲であるから"DESERTU.EDU"に設定するべきです。
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.
これは１つ以上のほんの最適化ハックです。ローカル管理者はローカルに管
理されたドメインの名前の割当ての制御を持ちます、それで管理者は省略が
正しい結果をもたらすことを確かにすることができます。ローカル制御下以
外で、ユーザーが必ず危険な状態です。
A more stringent mechanism is implemented in BIND 4.9.2, to respond
to this problem:
この問題に答えるためにBIND 4.9.2に緊急のメカニズムが実装されます：
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.
さらに、"."を含む名前は完全に指定された名前（FQDN）と仮定すべきで、最
初にそのままの名前として検索するべきです。
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:
例： user@a.b.c.dがe.f.g.hにつなごうとしている状態で、２つの試み
だけが暗黙の捜索リストを使って試みられるべきである：。
e.f.g.h. and e.f.g.h.b.c.d.
e.f.g.h. と e.f.g.h.b.c.d.
Given user@a.b.c.d. connecting to host those same two
tries would appear as:
user@a.b.c.dがホストにつなごうとしている状態で、同様の２つ
の試みだけがあわられます：。
x.b.c.d. and x.
x.b.c.d. と 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
ある組織が複数の部分の、部分的に指定されたドメイン名を通常使用します。
例えば、ホストfoo.loc１.org.city.state.usはbar.loc2やmumble.loc3の参
照をし、全てで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.
BIND 4.9.2の厳格な暗黙の捜索規則はこれらの捜索を失敗させるでしょう。
それらが成功するためには、クライアントリゾルバ設定がorg.city.state.us
を明示的な捜索規則を含めなければなりません。すなわち、探索リストの一
部としたいローカル管理サブドメイン明示的な規則を含んでいなくてはなり
ません。
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