<前の日記(2005-09-30) 次の日記(2005-10-11)> 最新

おおいわのこめんと (2005-10-01)


2005-10-01

[Security] (Amit Klien) Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and a lot more...

だんだん個人ブロクで書くネタじゃ無くなってきたな……。

Mozilla からの XMLHTTP の脆弱性の発表 の直後に発表されたレポート。 JVN #31226748 が出たのと前後してしまったので、

 マイクロソフト  	 該当製品なし  	2005/09/29

が波紋を呼んでいる模様。当初レポート出した時点で、SPACE とかを埋められないことを確認して、 「脆弱性無し」って報告しちゃったんだよねぇ。まさか、ちゃんと SP は除去してるのに HT や CR は通るとは思わないよなぁ……。

そういうわけで、時間軸が1日前後してしまったので混乱していますが、基本的には 「『脆弱性なし』とリリースした後に、類似パターンの脆弱性が見つかった」という 状況だと思って構わないと思います。MS が脆弱性が有るのを知っていて「無し」と 報告したというような話ではありません。

で、問題の件なのですが、状況を整理すると、

  1. まず、ユーザに影響のあるセキュリティ問題が生じているのは間違いない。
  2. MSIE のバグが問題なのも間違いない。かなり危ない動作をしているので直すべき。
  3. が、結果としての脆弱性が 100% MSIE だけの責任かといわれると微妙。

なので、Klien 氏のレポートはその辺り正しい(ツッコまれないような記述になっている、ともいう)のだが、 Secunia のアドバイザリ が MSIE だけの脆弱性にしているのはちょっと微妙かなぁとも思います。 まぁ、少なくとも 95% は MSIE の責任だけどね。

まず、おさらいしておかなきゃいけないのは、規格上

  • HTTP 1.1 のリクエスト行は、「リクエストメソッド」 SP 「URL」 SP 「HTTP-Version」 CRLF。SP は空白文字 (0x20) のみ。
  • HTTP 1.1 のリクエストメソッドに許されるのは "token"。token に許されるのは、アルファベット・数字と一部の記号。

ということです。その上で、

  • MSIE は、XMLHTTP においてリクエストメソッドに SP を入れることは許さないが、 それ以外の制御文字はすべて入れられてしまう。例えば、CR とか LF とか HT (水平タブ、0x09) とか。
  • 一方で、Apache とか多くの proxy は、SP の代わりに HT を使ったリクエストも受け付けてしまう。

という風に両方がおかしな処理をしているので、結果として、リクエストメソッドの部分を使って 怪しげなデータを送り込んで、proxy が URL とか次のヘッダとかと解釈するように仕向けることが できるという話です。通信の双方が HTTP に準拠していない データを違う風に解釈しているという状況です。

今回は、そもそも処理を開始しているのが MSIE の側ですし、 攻撃に使う文字が 改行 とか HT とか、明らかに「空白っぽい」文字ですし、 そもそも「リクエスト行」と命名されているデータに改行が含まれるのは感覚的に言って明らかにオカシイので、 まぁ MSIE が悪く言われるのも仕方がない気もしますが、一方で、この攻撃で生成される データが HTTP リクエストとして正当でないことは保証されているので、 proxy サーバ側は「400 Bad Request を返して (あるいは黙って) keepalive せずに TCP 接続を切断する」 という動作をすべきなのも間違いないです。 そのような厳格な動作をしている限り、今回の Klien 氏の攻撃は深刻な状況を生まないはずです。

HTTP Request Smuggling 系の攻撃は、ほぼ全てがこの手の「不正・異常な入力に対する サーバ・クライアント間の解釈の不一致」を突いて、それがセキュリティ的にやばい 不一致になるように攻撃を仕組むというパターンだと言えるので、両方をきちんと 直さないといけないのです。今回の件の MSIE の仕様は余り弁護できませんが、 過去に指摘された Smuggling の中には、「web server にそんな異常な動作されたら proxy はたまらないよなー」というような攻撃も結構あります。

一方で、実は今回の JVN #31226748 の 件の“味噌”は、解釈の一意に定まる HTTP/1.1 準拠のリクエストを使って攻撃が成功する、 という点にあります。今回僕が見つけた攻撃パターンは3つあるのですが、 そのうちの2つは HTTP/1.1 に完全準拠した正当なリクエストを生成していますし、 もう1つは HTTP/1.1 では「エラー」とされているものの、その際の受信側の 解釈が厳格に規定されているようなリクエストを生成しています。 つまり、これはサーバ側は「俺はちゃんと規格通りに解釈したぜ、 完全にクライアント側が一方的に悪い」と言いきれるケースなのです。 その辺りが、既存の攻撃とは違うパターンかな、と思っています。

ちなみに、最後のケースについてもう1レベル上のレベルから話をすると、 そもそもこういう不一致を生みやすい HTTP/1.1 の仕様自体にも、安定性という意味では問題があるといえます。 今回は Mozilla も Opera も HTTP/1.1 をサポートしているので 言い訳できませんが、実はこの「エラー」リクエストは、 HTTP/1.0 としてならクライアント側の解釈が正しい、とも言えるケースなのですね。 ですから、今後例えば HTTP/1.2 に変な機能が追加される(そしてサーバが HTTP/1.1 に遡って機能をサポートしてしまう)と、 今の安全な実装が次の脆弱性を産み出してしまう可能性があるわけです。 こんな危険を生むような仕様の改変は、できる限りするべきではありませんし、 中でも「誤ったデータの解釈」を定義する際には特に、この手の互換性と安全性に気を配らないといけません。 この辺り、きちんと纏めないといけないかもしれませんね。

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20051001 (note: TrackBacks are moderated: spams will not be shown.) ]

大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)