Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ（ルート化必要）が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostのIPアドレスを記述することも問題と指摘がありました。

@shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。

— Kietaさん (@typex20)

9月 23, 2012

これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事にて、hostsファイルにて127.0.0.1を指定するのは危険ではないと反論がありました。

さらに、私からは、以下のようにソースを示すよう提案したのですが、返答はなく、なかのきえた氏からブロックされてしまいました。

既知と言われるのなら、ソースを示すべきでは? RT @typex20: @cause_less あなたは何もわかっていないようですね。あなたがどのような被害に遭われても構いませんが他の人を巻き込まないようにしましょう。本件は既知の問題であり、適切とされる対処方法も存在する…

— 徳丸　浩さん (@ockeghem)

9月 24, 2012

その後、なかのきえた氏から「既知の問題に対するソース」は提示されていないようですが、その代わりに、下図の仮説が提示されました（クリックして拡大）。

おそらくこれが、hostsファイルにループバックアドレス(127.0.0.1)を指定することの脅威の説明なのだろうと仮定して、以下、上図について検討します。 この図によると、hostsファイルにループバックアドレスを指定することにより危険になる前提として以下が書かれています。

• Android端末上の8080ポートでhttpサーバが稼働して、そこに秘密情報がある（ポート番号8080は例であり何でも良い）
• このhttpサーバは外部からはアクセスが拒否される
• 利用者が使用しているブラウザは同一生成元ポリシーを無視するよう改造されている
• 利用者はmalcious_hostB（原文ママ。正しくはmalicious-hostAなどとすべき）のコンテンツを利用する
• malcious_hostBは広告をmalcious_hostAから読み込んでいる
• 利用者は広告よけのためmalcious_hostAのIPアドレスをhostsファイルで127.0.0.1に割りあてている

この前提から情報漏洩するシナリオですが、図にmalcious_hostBのコンテンツ中に、<iframe src=“malcious_hostA:8080/hogehoge.html”>が置かれ、malcious_hostA（localhostを指す）の情報を抜き取っているため、malcious_hostBのコンテンツには悪意があるというシナリオなのでしょう。

問題はここからです。上記の前提を受け入れるならば、確かにmalcious_hostBからlocalhostの情報を抜き取ることができます。しかし、これ以外のもっと簡単な方法では抜き取れないのでしょうか?

その方法はあります。malcious_hostBは悪意のあるコンテンツなのですから、localhostを指す方法として、malcious_hostAを使わなくても、localhost、あるいは 127.0.0.1 を直に指定することができます。malcious_hostAに127.0.0.1が指定する利用者は少数であると予想され、一方、localhost、あるいは 127.0.0.1 をすれば確実です。攻撃者がわざわざmalcious_hostAを使う動機（メリット）がありません。

ということから、hostsファイルにループバックアドレスを指定していなくても、上記シナリオによる情報漏洩は可能であり、hostsファイルにループバックアドレスを指定することにより脅威が増すことはありません。

脅威の考え方について

上記を一般化すると、次のように考えることができます。ある攻撃のシナリオが、条件A、条件B、条件Cに依存しているとします。しかし、実際には条件Aと条件Bだけでも攻撃が可能だとしましょう。上記の例で言うと、条件Cは「hostsファイルにループバックアドレスが指定されたホストがある状態」です。

条件Cがなくても攻撃が成立するといっても、条件Cが脅威に無関係とは限りません。以下の場合は、条件Cも脅威の要因として捉える必要があります。

• 条件Cにより、攻撃の影響（深刻度）が増す
• 条件Cにより、攻撃が容易になる、あるいは攻撃の成功確率が増す

今回のケースでは、条件C（hostsファイルにループバックアドレスが指定されたホストがある）は、上記のいずれにも該当しません。すなわち、脅威に影響を与えないことになります。

まとめ

• hostsファイルにループバックアドレスを指定することによって、localhostの情報を抜き取られる脅威は増加しない
• 外部のワナサイトからローカルの情報が抜き取られる根本原因は、同一生成元ポリシーに欠陥のあるブラウザにある
• 同一生成元ポリシーが無視されるブラウザを使うと、すべてのサイトにXSS脆弱性があるのと同じ（あるいはそれ以上）危険性があるので、そもそもあり得ない前提
• なかのきえた氏の書かれた図には独自プロトコルのアプリも可能性として含まれているが、同様に検証可能
• 「あなたは何もわかっていないようですね」という言葉は滅多なことでは使わないにすることをお勧めします。僕も使わないことにします