最新

おおいわのこめんと (2006-11)


2006-11-05

[Work] 出張

オーストラリアに行ってきます。 南半球は初めてだったりする。

日本→オーストラリアは夜便しかないので、職場に出勤してから夜から深夜にかけて移動、という形ですね。 ヒコーキの中で眠れない私はどうしようかな、と今から考えてたりする。

本日のツッコミ(全1件) [メッセージを送る]

本店 [時差がない分、楽だったりしない? ]


2006-11-08

[Security] Flash による Referer 偽装攻撃の有効性

なんか僕が海外に出かけるとなにかしらの事件が起こっている気がする……。とりあえず今回の件は、単純に Flash の脆弱性なんで、とっとと update しましょう、まる。

で、Flash の実験環境がないので試せないでいるし、アドバイザリもまだちゃんと読んでいないのだが、あくまで一般論として言えば XMLHTTP のようなインタフェースを提供されている状態で、Referer が設定できるだけではセキュリティへの影響は限りなく低い。むしろ、ほかのヘッダが設定できる方がやばい。Flash の脆弱性に特異な状況があればぜひ知らせてほしい。

実際、この件は昨年9月の XMLHTTP インタフェース経由の Content-Length 偽装による Request Splitting 脆弱性をレポート した際に Bugzilla 上で議論したのですが、最終的に Mozilla には Referer 偽装を防ぐコードは入っていないはずです。 僕は「設定できる必要がない」「ブラウザが正確な値を知っている」ことから設定できないようにしたらどうかと提案したのですが、security fixに必要な最小限には含まれないということで却下された模様です。

CSRF 対策の観点でこれで問題がない理由は次のとおり。

  • 同一ドメインからセッション cookie が含まれる XMLHTTP リクエストで Referer 偽装したリクエストを送ることができる脆弱性が存在する場合、攻撃は成功する。しかし、この攻撃のためには同一ドメインのページにスクリプトを送り込む必要があり、その状況ではこの脆弱性がなくても他の方法で Referer 偽装を含むかなり柔軟な攻撃が可能である。基本的に、この状況で CSRF を防ぐ方法は存在しないと考えてよい。ちなみにこの同一ドメインでの Referer 偽装方法は既知の方法だと思う(だからこそ Mozilla.org では「同一ドメインならなにできてもOK」と割り切っていると思う)が、日本国内でどれくらい知られているか、書いてやばくないかどうか、ちょっと検討してから問題がなければここに書こうと思う。
  • 他ドメインからセッション cookie が含まれる XMLHTTP リクエストを送り込める (XMLHTTP の同一ドメインチェックがバグっている) 状況では、form が含まれるページを GET して内容を解釈し、適切な値をセットして POST リクエストを送り込めば、既存のセッションを利用して任意の有効なリクエストを送出できる。よって、この状態はブラウザの深刻なバグといえる。スクリプト origin の同一ドメインチェックがバグっている状況でも同じ。
    ちなみに、仮定上の話として、この仮想のバグが修正されていない危険な状況では、フォームやページに秘密情報を入れる対策は有効ではなく、次の対策が有効になる。
    • パスワードチェック(他ドメインから読み取れる内容がHTTPレイヤの内容に限られ、他ドメインページの DOM 木が読み書きできない場合)
    • パスワードを入力する画面から遷移するすべての画面を POST で設計し、セッションを hidden パラメータで管理する (同上)
    • Referer チェック(同上、かつこのヘッダが任意にセットできない場合)
  • 他ドメインからセッション cookie が含まれない XMLHTTP リクエストを送り込める場合、cookie に含まれるセッション情報を利用したセッション乗っ取り攻撃は成功しない。

というわけで、XMLHTTP タイプのインタフェースへの攻撃で「Refererが偽装できる」という主張は頻繁にされるのですが、(意図的に隠しているのでなければ)主張としては極めて弱い、という話でした。Referer 偽装は状況がややこしいのでよく勘違いされる(そもそも HTTP でなんでも偽装できるじゃん、みたいな誤解した話もよくありますね)のですが、本当にやばいケースは「他ドメインのページから、ブラウザ利用者の意図によらずに偽装して送出できるケース」だけです。ヘッダの制限されていない XMLHTTP 系インタフェースの本当の怖さは別のところにあります。

本日のツッコミ(全6件) [メッセージを送る]

Before...

おおいわ [基本的に、Web のセキュリティには HTTP + HTML + Javascript をデファクトスタンダードとす..]

masa__ [ありがとうございます。 そうなるとクロスドメインでヘッダがセット出来ることに起因する脆弱性はFlashの問題であり、..]

masa__ [すいません、お昼頃、変な例でコメントを書いてしまいました。 - RefererなどをHTMLエンコードせずに出力する..]

masa__ [質問ばっかりでは申し訳がないので、個人的な見解を以下にまとめてみました。コメントなど頂けると嬉しいです。 http:..]

おおいわ [読みました。  まず、1つ目の質問の僕の答えは Yes です。もちろん、敢えて「この手のクライアントの全ての脆弱性ま..]


2006-11-11

[Misc] 帰国

無事帰ってきました。Fail-Safe C のデモもきちんとしてきました。

機内ではできるだけうとうとするように努力はしていたのですが、 やっぱり半徹夜あけみたいな状態になってます。

しかし、朝6時30分に成田に着くと、交通手段が極めて乏しいのはもうちょっと 何とかした方がいいような気がする。 JRの特急NEXは7:42までない (土休日とは言え旅行鞄を持って上りの普通列車にラッシュ時間帯に乗るのはぞっとしない) し、 京成は無料特急すら7:30までない (各駅停車……) し……。 そういうわけで、結局成田からバスで帰京することにしたのだが、ひょっとしたら初めてかなぁ。


2006-11-13

[Security] 悪趣味な「月刊」セキュリティーホール

最近気に入らないのが、「Month of Kernel Bugs」とか、「Monthly Undisclosed Bug」の類の企画やってる連中。

ハッカーがセキュリティバグを見つけた際に、クラッカーとして悪用するか、 悪用せずに「適切に」利用するかの境界は、結局人のためになるか、 という一点につきると思う。どのように「人のためになるか」、については セキュリティ関係者の間でも議論が分かれていて、しばしば紛争になるのは 周知の通りかと思うが、大きく分けて次のような考え方があると思う。

ベンダ修正を待つべき派
結局ソフトウェアのバグを直せるのはベンダだけなのだから、 バグを見つけたらこっそりベンダに教えてあげて、 直った時点で公表するのが悪用を防いでみんなのためになる。
Full Disclosure 派
ベンダは基本的に可能な限り公表を遅らせようとするのが(経済原理の元で) 自然な対応なのだが、我々発見者が気付くような脆弱性は早かれ遅かれ 悪意を持った人に利用されるものだし、そもそもベンダが誠実にバグ修正して 公表するものだとは限らないのだから、一般人に広く脆弱性の存在を 一刻も早く知らせて、利用者が自己責任で自己防衛できるようにするべきである。
30日, 45日派(折衷案)
いきなりバグを完全公開するのは社会的リスクが大きすぎるが、かといって ベンダをいつまでも待っていることにすると、ベンダが自己の利益のために 公開を引き延ばすのを許容してしまいそれも社会のためにならないので、 日限を切って「待機」戦略から「公開」戦略に移行することで、 両者のいいとこどりもできるし、実質的に「待機」戦略を取りながら ベンダの悪意を持った引き延ばしだけを封じることができるのではないか。

ちなみに僕の個人的スタンスは基本は折衷案で、案件によるものの30日〜60日位の間で 第1次の判断をすべきだと思っているのだが……報告したっきり公表されてない 脆弱性がいくつかあるような気がするな……

で、これらの主張には一応どれも一理あって、優劣がすぐにつくものではないので、 特定のスタンスを現時点で強制することは行われていないと思う。

で、例の企画の問題点は、どれにも該当していないこと、それに尽きる。 まず、未修正脆弱性を一般公開する理由は、一刻も早い対応をベンダと ユーザの両方が取ることができるようにすることなので、 公開するならば可及的速やかに行うべきで、知っている脆弱性を 「1日1個」とか「1月1個」なんて出し惜しみするようなことをするべきではない。 また、当然ながらベンダに報告している様子もないし、報告していたとしても それぞれの事案の公開日時はそれぞれ判断されるべきであって、 毎日順番に公開なんてことは普通に考えたらあり得ないと思う。

結局、クラッカー的ハッカーなんだろうなぁと、単に有名になりたいだけか、 あるいは何も考えずに「脆弱性祭り」やってるだけなんだろうなぁと。 大体、脆弱性で祭りやる事自体が「人の弱みに付け込んでいる」ってことなわけで、 重大な案件であればあるほど報告者は淡々と振る舞うべきだと思っている。

というわけで、そういう類のとは、正直一線を画していきたいと思う。 脆弱性の公開後に記事を書いたことはいくつかあるし、人によっては 僕の記事でもいい印象を持たない人もあるかも知れないが、個人的には 「修正された脆弱性の情報は広く伝えるべきである」という点と、 「脆弱性の影響範囲とか深刻さ、対処方法など、自分が伝えるべき情報が ある」という点を踏まえてできるだけ控え目に正確な情報を書こうと 努力しているつもりである。ベンダ批判をする事もあるかもしれないが、 できるだけ明確な点を的確に(祭らずに)批判しようと心得ている。

本日のツッコミ(全2件) [メッセージを送る]

はせがわ [モノにもよりますがベンダ報告から2年が経過してもなお修正されていないようなものもあります。 http://proje..]

O_o [日本語インタビュー記事出ていましたね http://www.itmedia.co.jp/news/articles/..]


2006-11-16

[Misc] しっごとー、しっごとー♪

今週は何か午前中出勤が多いのですよ。というか、打ち合わせの予定もあるが、 オーストラリア出張の余波か日付が変わると睡魔に襲われてしまうので、 必然的に朝起きているというか。ある意味健康。

しかし、出張中に富士山のように積み上がった仕事は一向に片付かない orz。

……

……

……

詳細は大岩さんが技術文書の形式でそのうち書いてくれるだろう。

(どさっ (効果音))

うぎゃーーー。

形式まで指定されてるし (^^;;

富士山がモンブラン (標高4807m) になった気分 (^^;

ま、スコップでえっちらおっちらと地道に掘ることにしまつ orz

本日のツッコミ(全1件) [メッセージを送る]

こんの [たっぷーり しっごとー♪ ]


大岩 寛 (おおいわ ゆたか) <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)