複数のWikiクローンのファイル添付機能にXSSな脆弱性 46
ストーリー by Oliver
他のWikiも要チェック 部門より
他のWikiも要チェック 部門より
Elbereth曰く、"JVN(Japan Vendor Status Notes)の報告によると、Pukiwiki、Wikiもどき、Hiki、AsWikiといった複数のWikiクローンのファイル添付機能にクロスサイトスクリプティングにつながる脆弱性が存在するとのこと。これらのWikiクローンを使用しているサイトの管理者は対処をされたし。関連情報：
"
その他影響しそうなの (スコア:2, 参考になる)
Pukiwikiを元にXOOPS [xoops.org]のモジュールとして使えるB-Wiki [mydns.jp]がありますが、これも影響しそうです。とりあえず私は自分が利用しているところは修正ファイルを入れておきました。Pukiwikiのものがそのまんま使えるようです。
今更か (スコア:2)
・添付は使えないと不便
・添付の Content-Type を application/binary にしてダウンロードダイアログが出るようにしてXSSしとこう
・でも画像(好みによりswfも)はブラウザで表示できないとやっぱり不便
ってことで、自分なりの結論として、Wiki を実装するなら画像だけマトモな Content-Type を返して、それ以外は全部バイナリ扱いでダウンロードダイアログが出るようになれば良いということになってる。
Re:今更か (スコア:2, 参考になる)
判断しますから、添付を使わないが正しいかと．
でなければ各セキュリティゾーンのセキュリティの設定で
[その他]-[拡張子ではなく、内容によってファイルを開くこと]を
"無効にする"とすればいいかも．
ほかには ファイルを一回ローカルにダウンロードして、
アンチウィルスソフトによる検査をしてから開くという
手順を踏んでもいいと思います．
#価格コムで仕込まれたやつも.CSSに偽造した.chmを置いてましたね
#危険性は世の中のアプロダと一緒といえば一緒か(?)
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:今更か (スコア:1)
＃でも回避出来ちゃうような場合もありそう...
Re:今更か (スコア:2, 参考になる)
対してはやはり攻撃的なわけで、管理者がそれをチェックする
ことはできないわけです。
普通のウェブにしても管理者を信頼するしかないわけで、
同じ第三者と言えばそうなんですが…。
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
[OT]それは私の無脳が故 (スコア:1)
それを説こうとして必死こいても、聞いてもらえないって言う…。
結局利用者のポリシー任せ…。
// トラブルが起きないと言うことは、素敵な人だけのみが知る閉鎖したサイトである。
----
:oすずめのおやどはどこじゃろぉ
('>ぴよぴよ
Re:今更か (スコア:1)
Re:今更か (スコア:1, 興味深い)
ダウンロードするときは常に圧縮するとかしないと無理っぽいかも
正しい情報を書きましょう（was Re:今更か) (スコア:0)
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の範囲外である事には違いありませんが、次のヘッダを送信する
Wikiクローンって山ほどありますが... (スコア:2, 参考になる)
上のサイトは2年ほど前までの情報なんで、現在はまた事情が違うでしょうし。
# 最新のクローンリストのサイトきぼん。
基本的に
がやばいかもしれない、ということでいいのかな？
Re:Wikiクローンって山ほどありますが... (スコア:3, すばらしい洞察)
・第三者がファイルをアップロードして、添付表示する機能があるもの
は「やばい」ということですよね。
たいていのWikiクローンにはそういう機能があるから今回の話になったわけでしょうけど、
・アップローダー(うぷろだ)
・お絵描き掲示板
なんかも同じ問題を抱えていると思います。
Re:Wikiクローンって山ほどありますが... (スコア:0)
Bugzillaなんか山ほど動いてそうだけど、かといって添付をOFFにすると
実用面で問題が出るし。
# 開発担当者を狙い撃ちできそうな予感。
Re:Wikiクローンって山ほどありますが... (スコア:0)
いま、デスマーチプロジェクトに一筋の光が差し込んだ！
デスマーチリセットソリューション「うっかり八べえ」感染中！
Re:Wikiクローンって山ほどありますが... (スコア:1)
こんなにたくさん [ocn.ne.jp]あります。ええ、ほんと山のように。コロンブスの卵？ (スコア:2, 参考になる)
AsWikiやHikiは該当しないのでは？ (スコア:1)
http://jvn.jp/jp/JVN%23465742E4/index.html
のベンダ情報みると、AsWikiやHikiは「該当製品なし」と書いてありますが、この２つには脆弱性はないということなんじゃないですか？
Re:AsWikiやHikiは該当しないのでは？ (スコア:2, 参考になる)
http://jvn.jp/jp/JVN%23465742E4/270028/index.html
には、
2005/05/17 にリリースした Hiki 0.6.6 ならびに Hiki 0.8.0 preview1 にて修正しました。
となっています。
Re:AsWikiやHikiは該当しないのでは？ (スコア:2, 参考になる)
「2005/05/17 にリリースした Hiki 0.6.6 ならびに Hiki 0.8.0 preview1 にて修正しました。」
とありますし。
読み方が甘くてすみません...
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
> 該当製品なし 脆弱性該当製品がない場合
となっていて、「脆弱性なし」としか読み取れないです、自分は。
「脆弱性あり・対応済み製品あり」とかってステータスがあるべきなんじゃないかなあ。
# 自分はyukiwikiを使ってるんだけど、これも今回の脆弱性には無関係のようで。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
「該当製品なし」ですっとばしていました。ちゃんと確認しないといかんですね。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
Hikiも自サイトでは脆弱性に関する報告を目立つようにあげていないし、結構対応に差があるよな。
Re:AsWikiやHikiは該当しないのでは？ (スコア:4, 参考になる)
「ユーザーからファイルをアップロードできる」ようにするからには、こういう危険性を回避する方法はまったくないかと思います。
たとえば、単に画像をアップできる掲示板でも、JPEGファイルを用いて任意のコードが実行できるという脆弱性 [srad.jp]による危険はあるわけですよね。
Wikiもどきの対応 [moonrock.jp]:
A.添付機能を無効に
B.アップロード元ホスト・ファイル名・Content-Type に基づく添付可否条件が設定可能
PukiWiki [pukiwiki.org]:
回避策(1) 全体をリードオンリーに
回避策(2) 管理者だけが添付ファイルのアップロードができるように
回避策(3)(4) 添付ファイルのアップロードができないように
どちらも、根本的な解決じゃないですよね。
WikiもどきのBはまともそうに見えますが、
Internet Explorer の「拡張子もContent-Typeも無視してデータの内容を元にどうやって表示するかを決める」という困った仕様の
前には無力だと思います。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
表示については次の版で、Hikiと同じようにContent-Depositionヘッダフィールドによる対処を行う予定です。ただ、これって全てのブラウザで有効なのかしりませんので効果も今イチ把握出来てません。
ＤＯＮ
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
さすがに、ブラウザに脆弱性があって、Webソフト側の妥当な仕様がトリガーを引くパターンと、Wiki の仕様＋ブラウザの仕様 から引き起こされる脆弱性を同一に扱うのはどうかと思いますが...。
Wikiもどきの(B)が対策になっていない、というIEの仕様は非常に問題だと思うんですが、現状ではこれはWiki側がなんとかしないとまずいでしょうねぇ。
あと、AsWiki の態度は個人的には開き直りに見えて妥当ではないと感じています。これが「該当製品なし」に分類されてしまう JVN の分類も問題ですが。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1, 興味深い)
今回の問題は、通常の掲示板であれば、管理者以外は画像やテキストなどしか書き込みできないのが、Wiki等の添付ファイルのアップロード機能があるものではブラウザのXSS脆弱性を攻撃するファイルをアップロードできてしまう。
だからマズいんじゃない？
という話で、Wikiの仕様がトリガーとなってブラウザの脆弱性が現出するのですからJPEGファイルの問題と形としては一緒です。
あとは、その「Wikiの仕様」が妥当かどうかという話になる訳で・・・
ブラウザの脆弱性を攻撃するファイルのアップロードは全て「妥当な仕様ではない」と断ずるのであれば、JPEGファイルがアップロードできる掲示板なども全部「妥当な仕様ではない」という事になっちゃいますし。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
だから違うんだってばさ。今回の件に関して言えば、攻撃されたブラウザのXSS脆弱性というものはそもそも存在しません。
# スクリプトに絡むブラウザのバグで、XSSと似たような結果を生むものはありましたけど、今回の件とは別件です。
XSS攻撃は、バグのある Web アプリケーション (今回の場合 Wiki サーバのソフト) に怪しげなデータを送りつけて、偽物のスクリプトをあたかも本物の Web アプリケーションの出力した JavaScript のように見せかけて Web ページに埋め込んでやるという攻撃です。ブラウザが受信した HTML ファイルを見ると、どちらも本物のスクリプトのように見えます。本物に見える以上、基本的にはブラウザは言われた通りに（スクリプトに許される権限の範囲で）実行するのが仕様に沿った「正しい」動作です。最初にブラウザに脆弱性があって、それを攻撃する、というシナリオではそもそもないのです。
# 逆に言えば、本物のスクリプトがやろうとしてもできないこと（いきなりローカルディスクのファイルを勝手に送信しちゃうとか）は XSS 脆弱性だけを使っても実現できません。できたらそれは「ブラウザのバグ」ですね。
一方で JPEG のバグは、画像を表示しろとだけ指示されそれを受け入れたブラウザが、なぜかメモリ内容をブッ壊してわけのわからん機械語の実行を始めてしまうというバグですので、ブラウザの問題です。
誰も今ウィルス入りのソフトを実行してデータ盗まれたからって、ウィルスを実行する Intel/AMD の CPU はケシカラン、とは普通言いませんよね。だってウィルス入りソフトのコードは機械語としては悪い事するのが「正しい動作」なんですから、Intel/AMD の CPU にとっては言われた通りのことを忠実に僕として実行しただけで、基本的にはそこを責められても困ります。XSS とブラウザの関係も基本的にそれと同じことです。
＃『基本的には』と書くからにはもうちょっと厳密な話をしないといけない点があるんですが、それはまた今度……。
Re:AsWikiやHikiは該当しないのでは？ (スコア:0)
それは管理者が意図しないJavaScriptが埋め込めるというだけで、全然クロスサイトしてません。
JavaScriptに関する問題を何でもかんでもXSSというのはバカみたいですからやめましょう。
# バカみたいなだけでなく、問題の本質をわかりにくくする。
管理者が任意のファイルをアップロードできるという仕組みを用意した以上、攻撃性がある物を含め、任意のフ
Re:AsWikiやHikiは該当しないのでは？ (スコア:0)
Wikiの「どこの誰とも知れない第三者が編集できる」って性質自体問題ってことになってしまうような。
被害を受けるのが人かマシンか、もっともそういうレベルまで落とすのならHTTPなりTCPだって同様の問題を抱えることになりますが。
有害な情報を簡単にフィルタできないUAまたは文化の問題の
Re:AsWikiやHikiは該当しないのでは？ (スコア:3, すばらしい洞察)
# 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 とは別件です。
同様の脆弱性 (スコア:1, 興味深い)
脆弱性があるものがありますね。
添付ファイルを加工（というほどでもないが）したメールを送りつけることで、
情報を盗むことが可能かもしれません。
製品名等は伏せますが、
メーカーが対応してくれればよいのですが...
Content-Type無視するって (スコア:0)
Re:Content-Type無視するって (スコア:1)
仕様は公開されてるのに、どうしてこう誤った認識ばかりが広まるんだろう。
大雑把に言ってしまうと、IEがContent-Typeを無視するのは
・Content-Typeがない
・Content-Typeのsyntaxが正しくない
・application/octet-streamまたはtext/plain
の時ですよ。
Content-Typeを無視してるように見えますよ？＜IE (スコア:1)
＃今更なのですが:-)
・使用アップローダスクリプト：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ユーザー数は非常に多いため無視できない。
の２点にあると思います。
そして、IE対策を考えるならば、wikiの添付機能を安全なものとするためには「ファイルの内容を（IEとほぼ同様の方法で）検証し、ファイルの内容からファイルタイプを決定するようにする」しかないと思います。
＃嗚呼、この世にIEさえ存在しなければ。
Re:Content-Typeを無視してるように見えますよ？＜IE (スコア:1)
春の心はのどけからまし。
Re:Content-Typeを無視してるように見えますよ？＜IE (スコア:1)
世の中に 絶えて桜の なかりせば 春の心は のどけからまし(在原業平) [milord-club.com]
しかしそういわれているけどやっぱりそういう気分よりもないほうがいいのが強いような感じはあります。難しい。
Re:Content-Typeを無視してるように見えますよ？＜IE (スコア:1)
Re:Content-Typeを無視してるように見えますよ？＜IE (スコア:1)
User-Agent を見て、IEには添付ファイルを見せないようにする方が簡単だと思います。
「添付ファイルが見れない」という苦情に対しては、「IEは危険だから他のブラウザ使ってくれ」と対処 :-)
Re:Content-Typeを無視してるように見えますよ？＜IE (スコア:0)
Re:Content-Typeを無視してるように見えますよ？＜IE (スコア:0)
いえ、単に#737807 [srad.jp]が仕様 [microsoft.com]を読み誤っているだけです。「image/jpeg」は「known」MIMEタイプに列挙されているので、内容を sniff する動作で(IEの)仕様通りです。
もっとも、この仕様に書
Re:Content-Type無視するって (スコア:0)
Re:Content-Type無視するって (スコア:0)
ネットに転がってるファイルは信用しちゃいけない (スコア:0)
ネット上では従来から当然のことだったんじゃないでしょうか。
よくわからないサイトによくわからないけど面白そうなファイルがあったので、
ダウンロードして実行したら実はそれが悪意あるサイトにある悪意あるファイル
だった、といっても、それは実行した人がばかだった、ということになるのが
ネットというものじゃないでしょうか。
不特定多数がアップロードできる環境である以上、そこに置かれている
ファイルは信用しないというのが、常識的な対応だと思います。それを
いまさら脆弱性だと言われても...という感じ。まるで、添付ファイルを
開いたらウィルスだったりする可能性を排除できないからメールは脆弱だ、
と言っているようなものだと思う。でも、メールとはそういうものだという
ことをみんなが納得して、その上で使ってる。
ただ、メールの添付ファイルは危ないということをみんな知ってるけど、
Wikiの添付ファイルは危ないということは、かならずしもみんなが知ってる
わけじゃない、というところに、問題があるのだと思います。
Wikiの開発者や運営者の側ができることといえば、Wikiとはそういうもの
だから気をつけなさい、という警告を閲覧者に対して行うくらいのこと
ではないでしょうか。
Re:ネットに転がってるファイルは信用しちゃいけない (スコア:0)
Re:ネットに転がってるファイルは信用しちゃいけない (スコア:0)
更にその上(#737744)の、
> 当該Wikiとは関係ないところ(たとえば2chとか)に、
> その添付ファイルのURLを書いた場合には、
> そのファイルがWikiに添付されたファイルである、
> ということは分からなくなってしまいます。
ってのはそもそも
Re:ネットに転がってるファイルは信用しちゃいけない (スコア:0)