|
ネットワーク WG Request for Comments： 1535 分類： 情報提供 |
E. Gavron ACES Research Inc. 1993年10月 |
このメモは、インターネットコミュニティのために情報を提供します。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布に制限はありません。
本書は、 現在配布されているネームリゾルバクライアントのいくつかに存在する欠陥について論じます。 この欠陥は、ユーザが部分的なドメイン名を指定する時、 リゾルバによって行われるヒューリスティックな検索と関連するセキュリティ上の弱点を露出するものであり、 これは、（大規模ではありませんが）容易に攻略できます。 本書は、その欠陥、事例および解決を指摘します。
現在のDNS（ドメインネームサーバー）のクライアントは、 IPアドレスをドット（.）区切りで覚える負担を減らすように設計されています。 そのように、人が読むことができる名前を、 IPアドレスと他のRR（資源レコード）に翻訳します。 翻訳過程においては、完全修飾ドメイン名（FQDN）ではないホスト名も理解し、 扱うことが含まれます。
根元から表現するFQDNのフォーマットは、{name}{.}として表現され、 根元から表現されないドメイン名のフォーマットは、 {name}です。
ドメイン名は、区切られた多くの部分を持つ可能性があり、 それらは、典型的には、ホストとドメインとタイプを含みます。 （例： foobar.company.comおよび fooschool.university.edu）
最も広く使われている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.
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 等のドメインにおいては、 さらに悪いことになります。
DNS（ドメインネームシステム）と、そのソフトウェアの仕様は、 名前空間の従属的な部分について管理委任を認める区別をしない階層構造となっています。 名前空間の実際の管理は、 「パブリックな管理」と「ローカルな管理」に分かれています。 「パブリックな管理」は、 .comや.EDU等のトップレベルドメインに関係があります。 いくつかのドメインについては、管理は、 サブドメインレベルのものに関係があります。 複数レベルの「パブリックな管理」は、 国別のトップレベルドメインについて最も明白です。 例えば、 完全に指定したドメイン名 dbc.mtview.ca.us.で"mtview.ca.us"の部分は、 3レベルのパブリックな管理を表します。 左の部分のみが「ローカルな管理」の対象となっています。
現在の一般的である実践における発見的検索の危険は、 検索リストの上を検索する際に、 意図しない値に一致することにより検索を「横取り」することが可能なことです。 これはいかなるレベルにおいても潜在的に危険ですが、 エラーが「ローカルな管理」外のユーザに影響を与える場合、 完全に許容できません。
部分的なドメイン名を変換することを試みる時、DNSリゾルバは、 検索ホストのドメイン名を検索リストを得るために使います。 既存のDNSリゾルバは、「ローカルな管理」がなされた範囲の名前の部分を、 「パブリックな管理」がなされたものと区別しません。
少なくとも、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月. |
このメモは、あまりに寛容な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.