ネットワーク WG
Request for Comments: 1535
分類: 情報提供

E. Gavron
ACES Research Inc.
1993年10月

English

広く採用された DNS ソフトウェアについてのセキュリティ問題と提案された修正
(A Security Problem and Proposed Correction With Widely Deployed DNS Software)

このメモの位置づけ

このメモは、インターネットコミュニティのために情報を提供します。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布に制限はありません。

要旨 English

本書は、現在配布されているネームリゾルバクライアントのいくつかに存在する欠陥について論じます。この欠陥は、ユーザが部分的なドメイン名を指定する時、リゾルバによって行われるヒューリスティックな 検索と関連するセキュリティ上の弱点を露出するものであり、これは、(大規模ではありませんが)容易に攻略できます。本書は、その欠陥、事例および解決を指摘します。

背景 English

現在の DNS(ドメインネームサーバー)のクライアントは、IP アドレスをドット(.)区切りで覚える負担を減らすように設計されています。そのように、人が読むことができる名前を 、IP アドレスと他の RR(資源レコード)に翻訳します。翻訳過程においては、完全修飾ドメイン名(FQDN)ではないホスト名も理解し、扱うことが含まれます。

根元から表現する FQDN のフォーマットは、{name}{.} として表現され、根元から表現されないドメイン名のフォーマットは、 {name} です。

ドメイン名は、区切られた多くの部分を持つ可能性があり、それらは、典型的には、ホストとドメインとタイプを含みます。(例: foobar.company.com および fooschool.university.edu)

欠陥  English

最も広く使われている BSD の BIND リゾルバに基づく問題は、それらが DNS レコードが見つけるまで、指定されたホスト名にドメインの リストを加えて検索処理して、ホスト名を変換しようと試みることです。この「機能」は、BIND 4.9.2 の公式リリースにおいて、デフォルトでは使用不能です。

例: TELNET User@Machine.Tech.ACES.COM による
UnivHost.University.EDU へのの試み

リゾルバクライアントが"UnivHost.University.EDU"が"."で終わらないことを認識し、これは 、根元から表現された FQDN ではありません。そこで、資源レコードが見つ かるまで、次の組合せを試みるでしょう。:

UnivHost.University.EDU.Tech.ACES.COM.
UnivHost.University.EDU.ACES.COM.
UnivHost.University.EDU.COM.
UnivHost.University.EDU.

セキュリティ論点 English

EDU.COM ドメインが登録された後、ある時、一般的ではないアプリケーションが、ワイルドカード CNAME レコードにおいて、あらゆる .COM サイトからのあらゆる .EDU サイトに対する接続のすべてが、edu.com のサブドメインで私的に管理されるマシンに集束してしまうことを発見しました。

以降、本検討においては、この私的なサブドメインへ特定のホスト名が登録されること、または、類似のネームサブドメインが偽ホストを作るのに使われる可能性があることを明らかにします。

例: harvard.edu.com. CNAME targethost

これは、あらゆる .com サイトから Harvard.edu への接続が、偽装された targthost に集束し、targthost は、Harvard.edu ログインバナーを提供 して偽装する可能性があります。

これは、明らかに許容できません。COM.EDU、MIL.GOV、GOV.COM 等のドメインにおいては、さらに悪いことになります。

パブリックな名前空間管理とローカルな名前空間管理 English

DNS(ドメインネームシステム)と、そのソフトウェアの仕様は、名前空間の従属的な部分について管理委任を認める区別をしない階層構造となっています。名前空間の実際の管理は、「パブリック な管理」と「ローカルな管理」に分かれています。「パブリックな管理」は、.com や .EDU 等のトップレベルドメインに関係があります。いくつかのドメインについては、管理は、サブドメインレベルのものに関係があります。 複数レベルの「パブリックな管理」は、国別のトップレベルドメインについて最も明白です。例えば、完全に指定したドメイン名 dbc.mtview.ca.us. で"mtview.ca.us"の部分は 、3レベルのパブリックな管理を表します。左の部分のみが「ローカルな管理」の対象となっています。

現在の一般的である実践における発見的検索の危険は、検索リストの上を検索する際に、意図しない値に一致することにより検索を「横取り」することが可能なことです。これはいかなるレベルにおいても潜在的に危険ですが、エラーが 「ローカルな管理」外のユーザに影響を与える場合、完全に許容できません。

部分的なドメイン名を変換することを試みる時、DNS リゾルバは、検索ホストのドメイン名を検索リストを得るために使います。既存の DNS リゾルバは、「ローカルな管理」がなされた範囲の名前の部分を、「パブリックな管理」がなされたものと区別しません。

解決策(複数) English

少なくとも、DNS リゾルバは、検索リストを「ローカルな管理」部分に限定することにより、「ローカルな管理」と「パブリックな管理」の間に「境界」を与えなければなりません。これは、ローカル管理者によってコントロールされる名前空間の範囲を表すパラメータを要求します。

これは、狭い範囲から広い範囲まで、ローカルな管理ドメイン内における段階的検索を許可しますが、それ以上の検索をしないでしょう。

例えば、もしローカルユーザが検索をしようとしていた場合:

User@chief.admin.DESERTU.EDU から
starburst,astro.DESERTU.EDU,

ユーザが、単に chief.admin と入力し、検索が成功するのは妥当です。:

chief.admin.astro.DESERTU.EDU
chief.admin.DESERTU.EDU

しかし、次の例は、良くありません。

chief.admin.EDU

この場合、「検索(範囲)」の値は、ローカルDNS 管理者によってコントロールされる名前空間の範囲である"DESERTU.EDU"に設定される必要があります。

これは、単なる最適化以上の作業です。ローカル管理者は、「ローカルな管理」がなされたドメインの名前の割当てのコントロールを持ち、それゆえ、管理者は、省略が正しい結果をもたらすことを確認することができます。ローカルコントロール の圏外の場合、ユーザは、必ずやリスクにさらされます。

この問題に対応して、BIND 4.9.2 においては、より厳密な機構が実装されています。:

DNS 名前リゾルバクライアントは、「暗黙(IMPLICIT)」検索リスト IF ANY を、例として最初と最後 に示したもののみにするように絞りこみます。

いかなる追加的な検索は、明示的にリゾルバに設定しなくてはなりません。

DNS 名前リゾルバソフトウェアが部分的な名前を絶対 FQDN に変換を試みる際に、ホストの直接の親ドメイン以外について暗黙の検索リストを使ってはいけません (SHOULD NOT)

暗黙の検索リストを使い続けるリゾルバは、検索範囲をローカルに管理されたサブドメインに範囲を限定しなければなりません。

DNS 名前リゾルバソフトウェアが、この問題を起こす明示的な検索リストを事前設定すべきではありません。

さらに、ドット(.)を含む名前がある場合には、それは完全修飾された名前(FQDN)とみなす必要があり、最初にそのままの名前で検索する必要があります。

例: user@a.b.c.d が e.f.g.h に接続する例においては、2通りの試みのみが暗黙の検索リストを使って試みられるべきである 。:

e.f.g.h. と e.f.g.h.b.c.d.

user@a.b.c.d がホストに接続する例においては、同様の 2つの試みのみが次のように現れます。:

x.b.c.d. と x.

組織体には、複数の部分の、部分的に指定されたドメイン名を常用する者があります。 例えば、ホスト foo.loc1.org.city.state.us は 、bar.loc2 や mumble.loc3 の参照をし、全てで whatever.locN.org.city.state.us を参照します。

BIND 4.9.2 についての厳格な暗黙の検索規則は、今度は、これらの検索を失敗させます。それらが成功するためには、クライアントリゾルバ設定が org.city.state.us を明示的な検索規則に含めなければなりません。すなわち、検索リストの一部とするいかなる各ローカル管理サブドメインについて、明示的な規則を含んでいなければなりません。

参考文献

[1] Mockapetris, P.,
"Domain Names Concepts and Facilities",
STD 13, RFC 1034, USC/Information Sciences Institute, 1987年11月.
 
[2] Mockapetris, P.,
"Domain Names Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, 1987年11月.
 
[3] Partridge, C.,
"Mail Routing and the Domain System",
STD 14, RFC 974, CSNET CIC BBN, 1986年 1月.
 
[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, 1993年10月.
 
[5] Beertema, P.,
"Common DNS Data File Configuration Errors",
RFC 1537, CWI, 1993年10月.

セキュリティについての考慮事項 English

このメモは、あまりに寛容な DNS クライアントについての脆弱性を示しています。これは、将来、問題となる可能性を根絶する修正を指摘するものです。

著者のアドレス

Ehud Gavron
ACES Research Inc.
PO Box 14546
Tucson, AZ 85711

電話: (602) 743-9841

EMail: gavron@aces.com

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp

松本直人
情報処理振興事業協会
セキュリティセンター

EMail: n-matsu@ipa.go.jp


Copyright (C) The Internet Society (1993). All Rights Reserved.