パスワードを忘れた? アカウント作成
10174 story

複数のWikiクローンのファイル添付機能にXSSな脆弱性 46

ストーリー by Oliver
他のWikiも要チェック 部門より

Elbereth曰く、"JVN(Japan Vendor Status Notes)報告によると、Pukiwiki、Wikiもどき、Hiki、AsWikiといった複数のWikiクローンのファイル添付機能にクロスサイトスクリプティングにつながる脆弱性が存在するとのこと。これらのWikiクローンを使用しているサイトの管理者は対処をされたし。関連情報:

"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Elbereth (17793) on 2005年05月19日 17時29分 (#737469)
    #タレコミ文に書き忘れたというか、タレコミボタンを押した直後に気づいたのですが

    Pukiwikiを元にXOOPS [xoops.org]のモジュールとして使えるB-Wiki [mydns.jp]がありますが、これも影響しそうです。とりあえず私は自分が利用しているところは修正ファイルを入れておきました。Pukiwikiのものがそのまんま使えるようです。
  • by kawaz (15398) on 2005年05月19日 17時56分 (#737475) ホームページ
    Wiki のページ表示時にどんなに頑張って XSS 対策しても添付ファイル表示できるようにしてたら意味無いじゃんって話は大分昔からしてたと思うんだけどなぁ。

    ・添付は使えないと不便
    ・添付の Content-Type を application/binary にしてダウンロードダイアログが出るようにしてXSSしとこう
    ・でも画像(好みによりswfも)はブラウザで表示できないとやっぱり不便

    ってことで、自分なりの結論として、Wiki を実装するなら画像だけマトモな Content-Type を返して、それ以外は全部バイナリ扱いでダウンロードダイアログが出るようになれば良いということになってる。
    • Re:今更か (スコア:2, 参考になる)

      by yanagi (6075) on 2005年05月19日 18時23分 (#737487) ホームページ 日記
      IEだとContent-typeではなくファイルの中身を見て
      判断しますから、添付を使わないが正しいかと.
      でなければ各セキュリティゾーンのセキュリティの設定で
      [その他]-[拡張子ではなく、内容によってファイルを開くこと]を
      "無効にする"とすればいいかも.
      ほかには ファイルを一回ローカルにダウンロードして、
      アンチウィルスソフトによる検査をしてから開くという
      手順を踏んでもいいと思います.
      #価格コムで仕込まれたやつも.CSSに偽造した.chmを置いてましたね
      #危険性は世の中のアプロダと一緒といえば一緒か(?)
      --
      やなぎ
      字面じゃなく論旨を読もう。モデレートはそれからだ
      親コメント
      • by typer (9666) on 2005年05月19日 20時07分 (#737518) 日記
        Wikiがわで考えると、添付ファイルはfile(1) [freebsd.org]でContent-type:を決める様にしたら問題なしといえる?
        #でも回避出来ちゃうような場合もありそう...
        親コメント
        • Re:今更か (スコア:2, 参考になる)

          by yanagi (6075) on 2005年05月20日 4時47分 (#737675) ホームページ 日記
          fileで判定しても攻撃的なhtmlなりjpgなりは特定の環境に
          対してはやはり攻撃的なわけで、管理者がそれをチェックする
          ことはできないわけです。

          普通のウェブにしても管理者を信頼するしかないわけで、
          同じ第三者と言えばそうなんですが…。
          --
          やなぎ
          字面じゃなく論旨を読もう。モデレートはそれからだ
          親コメント
      • >#危険性は世の中のアプロダと一緒といえば一緒か(?)

        それを説こうとして必死こいても、聞いてもらえないって言う…。
        結局利用者のポリシー任せ…。

        // トラブルが起きないと言うことは、素敵な人だけのみが知る閉鎖したサイトである。
        --

        ----
        :oすずめのおやどはどこじゃろぉ
        ('>ぴよぴよ
        親コメント
    • by kawaz (15398) on 2005年05月19日 18時03分 (#737479) ホームページ
      よく確認せず勢いで投稿してしまったがダウンロードするときの Content-Type は application/octet-stream ですね。
      親コメント
      • Re:今更か (スコア:1, 興味深い)

        by Anonymous Coward on 2005年05月19日 18時20分 (#737485)
        セキュリティホールmemo [ryukoku.ac.jp]にも書いてありましたが、IEはContent-typeを無視するようなので、それでもいまいちかも…。
        ダウンロードするときは常に圧縮するとかしないと無理っぽいかも
        親コメント
    • application/binary なんてメディアタイプはIANAに登録されていません。# 古いRFCにapplication/binaryを言う記述はありますが。

      http://www.iana.org/assignments/media-types/application/

      登録されていないメディアタイプを使う場合、application/x-hogeとします。

      http://www.ietf.org/rfc/rfc2425.txt

      元々メール用のヘッダであった物をブラウザで実装しているも物が多い、というだけです。RFCにもその記載があります。

      http://www.ietf.org/rfc/rfc2616.txt

      IEがどう実装していようとRFCの範囲外である事には違いありませんが、次のヘッダを送信する
  • by SaySet (18192) on 2005年05月19日 18時39分 (#737491) 日記
    たとえば ここ [yamdas.org]とかここ [yamdas.org]とかをみると、一口でWIKIクローンといっても結構いろいろありますよね。
    上のサイトは2年ほど前までの情報なんで、現在はまた事情が違うでしょうし。
    # 最新のクローンリストのサイトきぼん。

    基本的に
    • Web公開用のWIKIで(したがってPalmWikiやひとりWiki?は除外)
    • ファイル添付機能のあるもの(YukiWikiは外れる?)
      がやばいかもしれない、ということでいいのかな?
  • by patagon (1453) on 2005年05月20日 8時00分 (#737692) 日記
    Wiki のファイル添付の脆弱性(水無月ばけらのえび日記) [bakera.jp]

    話は単純で、「任意の HTML ファイルが添付できる」というだけです。HTML を用意し、添付します。添付されたファイルにアクセスすると、普通に HTML が表示されます。ただそれだけのことで、特別な細工は何も必要ありません。

    スクリプトを含む HTML も添付できますので、悪意あるスクリプトを含む HTML を添付すれば攻撃が成立します。HTML が添付できることにはみんな気づいていたと思うのですが、それが悪用できるということに気づいていなかった……という感じでしょうか。
  • タレコミのリンク先
    http://jvn.jp/jp/JVN%23465742E4/index.html
    のベンダ情報みると、AsWikiやHikiは「該当製品なし」と書いてありますが、この2つには脆弱性はないということなんじゃないですか?
    • by to (16347) on 2005年05月19日 17時32分 (#737470)
      Hiki の JVN#465742E4 への対応
      http://jvn.jp/jp/JVN%23465742E4/270028/index.html
      には、
            2005/05/17 にリリースした Hiki 0.6.6 ならびに Hiki 0.8.0 preview1 にて修正しました。
      となっています。
      親コメント
    • by temple_craft (13186) on 2005年05月19日 17時36分 (#737471)
      よく読むと「該当製品なし」=「脆弱性なし」、ではなく、現在は対策済みという意味なんでしょうか。Hikiは
      「2005/05/17 にリリースした Hiki 0.6.6 ならびに Hiki 0.8.0 preview1 にて修正しました。」
      とありますし。

      読み方が甘くてすみません...
      親コメント
      • 「JVNの読み方」の「ベンダ情報 [jvn.jp]」を見ると、
        > 該当製品なし 脆弱性該当製品がない場合
        となっていて、「脆弱性なし」としか読み取れないです、自分は。

        「脆弱性あり・対応済み製品あり」とかってステータスがあるべきなんじゃないかなあ。
        # 自分はyukiwikiを使ってるんだけど、これも今回の脆弱性には無関係のようで。
        親コメント
    • #コメント書いてるうちに他の人にフォロー書かれたので省略ですが、

      「該当製品なし」ですっとばしていました。ちゃんと確認しないといかんですね。
      親コメント
    • AsWikiは
      attach pluginを利用したときに、危険なファイルを添付されて危険だという指摘を頂いてますが、それはそういうものです。デフォルトで使用してませんので、自分でリスクを理解して設定して下さい。開発側でチェックコードを入れるとかはしません。
      という態度。なんだかなー。
      Hikiも自サイトでは脆弱性に関する報告を目立つようにあげていないし、結構対応に差があるよな。
      親コメント
      • 態度はともかく、対応としてはそういうものじゃないでしょうか。
        「ユーザーからファイルをアップロードできる」ようにするからには、こういう危険性を回避する方法はまったくないかと思います。

        たとえば、単に画像をアップできる掲示板でも、JPEGファイルを用いて任意のコードが実行できるという脆弱性 [srad.jp]による危険はあるわけですよね。

        Wikiもどきの対応 [moonrock.jp]:
         A.添付機能を無効に
         B.アップロード元ホスト・ファイル名・Content-Type に基づく添付可否条件が設定可能

        PukiWiki [pukiwiki.org]:
         回避策(1) 全体をリードオンリーに
         回避策(2) 管理者だけが添付ファイルのアップロードができるように
         回避策(3)(4) 添付ファイルのアップロードができないように

        どちらも、根本的な解決じゃないですよね。

        WikiもどきのBはまともそうに見えますが、
        Internet Explorer の「拡張子もContent-Typeも無視してデータの内容を元にどうやって表示するかを決める」という困った仕様の
        前には無力だと思います。
        親コメント
        • WikiもどきのBは添付ファイルの表示時ではなくて、添付ファイルをアップロードする際の制限です。すでにアップロードされたものに対しては制限していません。

          表示については次の版で、Hikiと同じようにContent-Depositionヘッダフィールドによる対処を行う予定です。ただ、これって全てのブラウザで有効なのかしりませんので効果も今イチ把握出来てません。
          --
          DON
          親コメント
        • > たとえば、単に画像をアップできる掲示板でも、JPEGファイルを用いて任意のコードが実行できるという脆弱性による危険はあるわけですよね。

          さすがに、ブラウザに脆弱性があって、Webソフト側の妥当な仕様がトリガーを引くパターンと、Wiki の仕様+ブラウザの仕様 から引き起こされる脆弱性を同一に扱うのはどうかと思いますが...。

          Wikiもどきの(B)が対策になっていない、というIEの仕様は非常に問題だと思うんですが、現状ではこれはWiki側がなんとかしないとまずいでしょうねぇ。

          あと、AsWiki の態度は個人的には開き直りに見えて妥当ではないと感じています。これが「該当製品なし」に分類されてしまう JVN の分類も問題ですが。
          親コメント
          • by Anonymous Coward on 2005年05月19日 19時52分 (#737516)
            さすがに、ブラウザに脆弱性があって、Webソフト側の妥当な仕様がトリガーを引くパターンと、Wiki の仕様+ブラウザの仕様 から引き起こされる脆弱性を同一に扱うのはどうかと思いますが...。
            いつのまにXSSがブラウザの仕様になったのでしょうか?

            今回の問題は、通常の掲示板であれば、管理者以外は画像やテキストなどしか書き込みできないのが、Wiki等の添付ファイルのアップロード機能があるものではブラウザのXSS脆弱性を攻撃するファイルをアップロードできてしまう。
            だからマズいんじゃない?
            という話で、Wikiの仕様がトリガーとなってブラウザの脆弱性が現出するのですからJPEGファイルの問題と形としては一緒です。

            あとは、その「Wikiの仕様」が妥当かどうかという話になる訳で・・・
            ブラウザの脆弱性を攻撃するファイルのアップロードは全て「妥当な仕様ではない」と断ずるのであれば、JPEGファイルがアップロードできる掲示板なども全部「妥当な仕様ではない」という事になっちゃいますし。

            親コメント

            • 今回の問題は、……だからマズいんじゃない? という話で


              だから違うんだってばさ。今回の件に関して言えば、攻撃されたブラウザのXSS脆弱性というものはそもそも存在しません。

              # スクリプトに絡むブラウザのバグで、XSSと似たような結果を生むものはありましたけど、今回の件とは別件です。

              XSS攻撃は、バグのある Web アプリケーション (今回の場合 Wiki サーバのソフト) に怪しげなデータを送りつけて、偽物のスクリプトをあたかも本物の Web アプリケーションの出力した JavaScript のように見せかけて Web ページに埋め込んでやるという攻撃です。ブラウザが受信した HTML ファイルを見ると、どちらも本物のスクリプトのように見えます。本物に見える以上、基本的にはブラウザは言われた通りに(スクリプトに許される権限の範囲で)実行するのが仕様に沿った「正しい」動作です。最初にブラウザに脆弱性があって、それを攻撃する、というシナリオではそもそもないのです。
              # 逆に言えば、本物のスクリプトがやろうとしてもできないこと(いきなりローカルディスクのファイルを勝手に送信しちゃうとか)は XSS 脆弱性だけを使っても実現できません。できたらそれは「ブラウザのバグ」ですね。

              一方で JPEG のバグは、画像を表示しろとだけ指示されそれを受け入れたブラウザが、なぜかメモリ内容をブッ壊してわけのわからん機械語の実行を始めてしまうというバグですので、ブラウザの問題です。

              誰も今ウィルス入りのソフトを実行してデータ盗まれたからって、ウィルスを実行する Intel/AMD の CPU はケシカラン、とは普通言いませんよね。だってウィルス入りソフトのコードは機械語としては悪い事するのが「正しい動作」なんですから、Intel/AMD の CPU にとっては言われた通りのことを忠実に僕として実行しただけで、基本的にはそこを責められても困ります。XSS とブラウザの関係も基本的にそれと同じことです。

              #『基本的には』と書くからにはもうちょっと厳密な話をしないといけない点があるんですが、それはまた今度……。
              親コメント
              • >XSS攻撃は、(以下略)

                それは管理者が意図しないJavaScriptが埋め込めるというだけで、全然クロスサイトしてません。
                JavaScriptに関する問題を何でもかんでもXSSというのはバカみたいですからやめましょう。

                # バカみたいなだけでなく、問題の本質をわかりにくくする。

                管理者が任意のファイルをアップロードできるという仕組みを用意した以上、攻撃性がある物を含め、任意のフ

          • >あと、AsWiki の態度は~
            Wikiの「どこの誰とも知れない第三者が編集できる」って性質自体問題ってことになってしまうような。

            被害を受けるのが人かマシンか、もっともそういうレベルまで落とすのならHTTPなりTCPだって同様の問題を抱えることになりますが。

            有害な情報を簡単にフィルタできないUAまたは文化の問題の
            • by Oiwa (6627) on 2005年05月19日 20時17分 (#737525) ホームページ
              ええと、今 aswiki のソースを2分間くらい読んでいるんですが、「そういうものです」という開き直ったような Web ページの書き方とは裏腹に、ひょっとしたらそもそも今回の脆弱性は存在しないかも... という気がしてきました。あとでインストールして確かめてみます。
              # Content-disposition: attachment を出力している気配があります。

              ですので、ここから先は脆弱性があるという前提での話としてですが...

              で、元コメントですが、Wiki の「誰でも編集できる」ことそれ自体、社会的・人的被害 (SPAM とか誹謗中傷とか) というレベルでは脆弱性といえるかもしれません。それは Wiki の弱点であり、「読者側の人間は(Wiki がそういうものだと知っていれば)理性的に内容を取捨選択できる」という前提に依存したセキュリティモデルでもあります。個人的には広くインターネット全体に書き込み権限を許すのはあまり勧められた物ではないと考えてはいますが、まぁ全く許せないポリシーというわけではありません。

              しかし、Wiki が独自文法を強制して、HTML タグ (特に<SCRIPT>や<OBJECT>)を書けないようにするというのは、機械的にウィルスを埋め込まれないとか、cookie を盗まれないとか、そういった web アプリケーションソフトウェアとしての基本的な安全性を保証しているという意味で、重要なsecurity featureです。機械は誤った情報を人間のように賢く取捨選択することができませんから、きちんと機械が誤動作しないような情報をクライアントに送信するのは、Webアプリケーション側の責任です。

              今回の場合、きちんと処理をしておかないと、攻撃者は外部から添付ファイルにリンクを張ることで、上記の Wiki 構文の制限を回避して、Wiki 利用者(設置者)や Wiki 読者に限らず全ての Web ユーザに対し、いきなり Wiki 設置サイトの権限で任意の HTML ファイルを読み込ませ、Javascript を走らせることができます。これは、現在の Web ブラウザと Web アプリケーションの基本的な設計モデルからすれば許容できない脆弱性に当たります。

              一方で、きちんと処理された Wiki やアップローダから添付ファイルを「ダウンロード」した後、そのファイルを人間が開くか開かないかは、添付付き Wiki やアップローダを使う人間の問題になります。やばいファイルが添付されていれば、やばいことが起こりますが、それは「そういうものです」。今回の XSS とは別件です。
              親コメント
  • by Anonymous Coward on 2005年05月19日 21時27分 (#737541)
    Webメールや(ブラウザ上で動く)グループウェア等にも同様の
    脆弱性があるものがありますね。
    添付ファイルを加工(というほどでもないが)したメールを送りつけることで、
    情報を盗むことが可能かもしれません。

    製品名等は伏せますが、
    メーカーが対応してくれればよいのですが...
  • by Anonymous Coward on 2005年05月20日 0時42分 (#737604)
    IEの脆弱性と題したほうが適切だと思えますが。
    • IEだって、どんな時でもContent-Typeを無視するわけじゃないんですが。
      仕様は公開されてるのに、どうしてこう誤った認識ばかりが広まるんだろう。
      大雑把に言ってしまうと、IEがContent-Typeを無視するのは
      ・Content-Typeがない
      ・Content-Typeのsyntaxが正しくない
      ・application/octet-streamまたはtext/plain
      の時ですよ。
      親コメント
      • 今回のニュースを見て、自分の設置している画像アップローダがどの程度のセキュリティリスクを抱えているのか調べようと、以下の実験をしてみました。
        #今更なのですが:-)

        ・使用アップローダスクリプト:imgboard v1.22 R6.1c
        ・使用ブラウザ:Internet Explorer 6 SP1(Windows98SE)、
         FireFox1.0.4日本語版(Windows98SE)、Netscape Navigator 4.73(Windows98SE)

        拡張子を.jpgに変更したHTMLファイルを用意し
        ・IEでアップロード→ファイル拡張子が.htmlとなった
        #おそらくIEがファイルの内容からHTMLファイルと想定し、Content-type:text/htmlで送信した?
        ・NN,Foxでアップロード→ファイル拡張子が.jpgのまま
        #ファイル拡張子からjpegファイルと判定し、Content-type:image/jpegで送信?

        その後、.jpgとなったHTMLファイルへのリンクをクリックして開こうとした。
        ・IEで開く→HTMLファイルとして表示
        ・NN,Foxで開く→破損したjpegファイルとして表示

        以上を見る限り、Webサーバ側は.jpgとなったHTMLファイルについてはContent-type:image/jpegを送ってきているとしか思えません。
        そしてIEは、そのContent-Typeを無視しているとしか思えません。
        Mr. Hankey様の情報とは合致しないのですが、WindowsXPSP2+最新IEだと事情が異なるのでしょうか。

        と、少々話がそれましたが。
        各wikiのソースを読んだ訳ではありませんが、恐らくどのwikiの添付プラグインでも「ファイル拡張子からファイル種別を判別」か「Content-Typeからファイル種別を判別」でしょうから、恐らくこの実験と同様の結果が出ると思います。

        ----

        これにより考えられる攻撃シナリオですが。
        1)NN,Foxなどで、.jpg(等画像ファイル)に拡張子を変更した、悪意あるHTMLファイルをアップロード。
        2)上記.jpg(の拡張子を持つ、中身はHTMLのファイル)を開くと、IEの場合のみHTMLファイルとして表示し、悪意あるコードを実行
        でしょうか。

        通常の方法でHTMLファイルをアップロードするならば、アップロードされた添付ファイルのファイル名は.htmlになる訳で、管理者から「怪しいhtmlファイルは開くな」と強く警告しておくだけでもそれなりに被害を防ぐ事が出来ると思います。
        しかし、上記の方法でHTMLファイルを画像ファイルの拡張子でアップロードされてしまったら、ファイル名からは画像ファイルとしか見えません。IEユーザーは「その画像ファイルとおぼしきファイルを疑いもなく開いて、悪意あるコードを実行させてしまう」ことでしょう。

        要するに、本件の問題は、
        ・Webの誰かがアップロードしたファイルには危険性があるかもしれないのに、wikiに関してはこれまで誰も注意を払って来なかった。
        ・IEはContent-Typeを無視して、画像ファイルに偽装されたHTMLファイルをHTMLファイルとして表示してしまうため、特にIEユーザーの間で被害の拡大が懸念される。IEユーザー数は非常に多いため無視できない。
        の2点にあると思います。

        そして、IE対策を考えるならば、wikiの添付機能を安全なものとするためには「ファイルの内容を(IEとほぼ同様の方法で)検証し、ファイルの内容からファイルタイプを決定するようにする」しかないと思います。

        #嗚呼、この世にIEさえ存在しなければ。
        親コメント
      • こらこらこら。おいたしちゃいけません。
    • この件に関しては、たとえばPukiWikiなら、FirefoxでもXSSがあります。
  • by Anonymous Coward on 2005年05月20日 8時40分 (#737702)
    出自がはっきりしないファイルは信用しちゃいけない、というのは、
    ネット上では従来から当然のことだったんじゃないでしょうか。

    よくわからないサイトによくわからないけど面白そうなファイルがあったので、
    ダウンロードして実行したら実はそれが悪意あるサイトにある悪意あるファイル
    だった、といっても、それは実行した人がばかだった、ということになるのが
    ネットというものじゃないでしょうか。

    不特定多数がアップロードできる環境である以上、そこに置かれている
    ファイルは信用しないというのが、常識的な対応だと思います。それを
    いまさら脆弱性だと言われても...という感じ。まるで、添付ファイルを
    開いたらウィルスだったりする可能性を排除できないからメールは脆弱だ、
    と言っているようなものだと思う。でも、メールとはそういうものだという
    ことをみんなが納得して、その上で使ってる。

    ただ、メールの添付ファイルは危ないということをみんな知ってるけど、
    Wikiの添付ファイルは危ないということは、かならずしもみんなが知ってる
    わけじゃない、というところに、問題があるのだと思います。

    Wikiの開発者や運営者の側ができることといえば、Wikiとはそういうもの
    だから気をつけなさい、という警告を閲覧者に対して行うくらいのこと
    ではないでしょうか。

    • Wikiのページから、添付されているファイルのリンクを開くのならいいですが、当該Wikiとは関係ないところ(たとえば2chとか)に、その添付ファイルのURLを書いた場合には、そのファイルがWikiに添付されたファイルである、ということは分からなくなってしまいます。
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...