アカウント名:
パスワード:
私も、これを脆弱性と呼ぶのは違和感がありました。ただ、
厳密な言い方をするなら、脆弱性ではなく、仕様範囲内であっても使用者の意図と異なることが起こりうることをどう捉えるか、と言う問題ですね。
#598858でも書かれているように、仕様自体が脆弱性を内包していることもあり得ます。ですから、仕様通りの動作だから脆弱性ではない、ということはないかと思います。
どちらかと言えば私が気にしているのは、本当にこれは「ユーザーの意図せず行われる操作」なのか？ということです。
Explzhなどの一覧表示式アーカイバで件の書庫を開けば、相対パスでファイルが格納されていることは明らかに分かります。ユーザーはそれを確認した上で、解凍操作を行ないます。（ここで、書庫内の相対、絶対パス指定を無視するオプションは確かに欲しいですけどね……ありましたっけ？）
一方、問題になりそうなのは、「アイコンにドラッグだけで一発解凍」系ですが、これはあくまで、「書庫内を確認して解凍操作をする」という手順を省略しているに過ぎません。ユーザーはこのタイプのアーカイバを選択することで、自分の意志により内容確認の権利（というのは大げさかもしれませんが）を放棄していると言えます。この状態で意図しないディレクトリにファイルが解凍されても「確認しないのが悪いじゃん」としか言いようがない気がするのですが……。
実際に『脆弱性』を利用した書庫があり、それを内容を確認せずにダウンロードして解凍し、攻撃を受けたとして、それは「ウイルスに感染したEXEファイルをダウンロードし、ウイルスチェックをかけず、実行して攻撃を受ける」のと何が違うのだろうか、と思います。後者はWindowsのEXE実行機能の脆弱性なのでしょうか？
ついでに瑣末事ではありますが、
特に窓の杜の記事は、まるで自分たちが「発見」したみたいな書き方で非常に不愉快ですね。
なお、脆弱性の悪用拡大を防止する目的で、情報元などの詳細に関しては割愛する。
とありますね。情報元ページには悪用可能で未対処な脆弱性がたくさん載っていたわけですから、大手メディアとしては妥当な判断ではあると思います。批判を受けてこっそり追記、などではなく最初からあったはずです。メール版にも載っていますし。
まあ、今更であることは変わり在りませんが。また、一つのウェブサイトに書いてあったことを鵜呑みにしていきなり記事にしてしまうのもどうかと……。それこそ、shoda T.さんのような「専門家」に相談して裏を取ってからのほうがよかったのでは、と思いますね。
以下オフトピ御免……。 きっとshoda T.さんが黙っちゃいないだろう、と思っていました。次回の某ニュースのネタはこれかな（笑）。
一方、問題になりそうなのは、「アイコンにドラッグだけで一発解凍」系ですが、これはあくまで、「書庫内を確認して解凍操作をする」という手順を省略しているに過ぎません。ユーザーはこのタイプのアーカイバを選択することで、自分の意志により内容確認の権利（というのは大げさかもしれませんが）を放棄していると言えます。
まず、今回脆弱性とされている問題は、書庫内の相対パス指定によりユーザーが指定したフォルダの上位フォルダにファイルが展開されることがあるのが原因、という点を確認しておきます。（そういえばこの前提を知らないと成り立たない議論かも……窓の杜の記事にはないですね）
ソフトの説明に、「指定フォルダに展開する」と書かれているのであれば、指定していないフォルダに展開するのは「バグ」かつ「脆弱性」です。
「指定フォルダ」の定義によります。冒頭に述べたように、今回問題になっているような書庫では、「ユーザーが指定したフォルダ＋書庫内にある上位に向けた相対パス」を元にファイルの展開先が決められます。
それを脆弱性と言うならば、書庫内にサブフォルダがあった場合に、展開先にサブフォルダが作成されるのも、「指定フォルダ」ではないという意味では同様であり脆弱性となりますが、その理解でよろしいですか？ 私は違うと思います。以上のことから私は「指定フォルダ」というのは「ユーザーが指定したフォルダ＋書庫内で指定されているフォルダの合算」と理解しています。
もし、「書庫内のフォルダ構成を無視して展開する」オプションがあるアーカイバで、オプションONでもこの相対パス指定が効いてしまうようなら、それは当然脆弱性でしょうけれど。
（ついでに、たとえ脆弱性だったとしても、仕様通りの動作なので「バグ」ではないですが、別の話になるので割愛。）
EXEファイルを実行して攻撃を受ける可能性は多くの人が認識していますが、書庫ファイルを展開しただけで攻撃を受ける可能性は多くの人が認識していないという違いがあります。
脆弱性であるかどうかを決める基準に、「多くの人が認識している」という要素はあるのでしょうか？ 先にMatsuTakeさんが引かれたe-Wordsにもそのような定義はないようですが。
それとも、どちらも脆弱性であるが、多くの人が認識していない脆弱性のほうがより危険である、という主張でしょうか。それでしたら（そのこと自体には）同意します。
それを脆弱性と言うならば、書庫内にサブフォルダがあった場合に、展開先にサブフォルダが作成されるのも、「指定フォルダ」ではないという意味では同様であり脆弱性となりますが、その理解でよろしいですか？
脆弱性であるかどうかを決める基準に、「多くの人が認識している」という要素はあるのでしょうか？
サブフォルダが作成されることにより、ディレクトリエントリがディスク上に確保されることで、ユーザが意図しないディスク領域を利用されてしまう脆弱性……とかいう言い方をしたら、攻撃を受けている形になりますか?
ユーザの意図しない挙動が発生すること、というのが最も重要なのではないでしょうか。
BMP bombレベルになれば立派にDoS攻撃を受ける脆弱性だと思いますが、ディスク領域が使われること自体を「意図しない」と言うのはかなり苦しいと思います。サブフォルダだけでそんなに大量のディスク領域が消費されるんですか?
意図しない電力が消費される脆弱性。対策: 電源を入れないこと
塵も積もれば邪魔となるものですから。
それと、.lzh や .zip などを利用可能な全てのプラットフォームにおいて発生しうる問題という事を考えると、少し前の WinCE 機などでは、1byte でも削りたいとか言うことになると思いますが。
書庫上では数バイト程度のディレクトリエントリ情報が、ディスク上に展開されると数百バイトから数キロバイトの範囲 (クラスタサイズ等に依存) に増加するわけで、dir bomb も可能と言えるものでしょう。
これを「はぁ?」と思うのであれば、書庫展開により予期しない場所にファイルを作成されうる問題も、同程度に「はぁ?」だと思いますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
窓の杜の情報元は (スコア:0)
Re:窓の杜の情報元は (スコア:5, 参考になる)
何もかも脆弱性の一言で片付けてしまうと、本当の危険が隠れてしまいそうな気がするので、こういう情報を流す人は、危険度のランク付けをして、出来れば言葉も変えてほしいなぁと思いますね。
そもそも問題とされていることは、かなり以前から directory traversal問題として議論されたことですね。なんで今更、と言う感がぬぐえないです。
特に窓の杜の記事は、まるで自分たちが「発見」したみたいな書き方で非常に不愉快ですね。
厳密な言い方をするなら、脆弱性ではなく、仕様範囲内であっても使用者の意図と異なるこ
Re:窓の杜の情報元は (スコア:2, 興味深い)
私も、これを脆弱性と呼ぶのは違和感がありました。ただ、
#598858でも書かれているように、仕様自体が脆弱性を内包していることもあり得ます。ですから、仕様通りの動作だから脆弱性ではない、ということはないかと思います。
どちらかと言えば私が気にしているのは、本当にこれは「ユーザーの意図せず行われる操作」なのか？ということです。
Explzhなどの一覧表示式アーカイバで件の書庫を開けば、相対パスでファイルが格納されていることは明らかに分かります。ユーザーはそれを確認した上で、解凍操作を行ないます。（ここで、書庫内の相対、絶対パス指定を無視するオプションは確かに欲しいですけどね……ありましたっけ？）
一方、問題になりそうなのは、「アイコンにドラッグだけで一発解凍」系ですが、これはあくまで、「書庫内を確認して解凍操作をする」という手順を省略しているに過ぎません。ユーザーはこのタイプのアーカイバを選択することで、自分の意志により内容確認の権利（というのは大げさかもしれませんが）を放棄していると言えます。この状態で意図しないディレクトリにファイルが解凍されても「確認しないのが悪いじゃん」としか言いようがない気がするのですが……。
実際に『脆弱性』を利用した書庫があり、それを内容を確認せずにダウンロードして解凍し、攻撃を受けたとして、それは「ウイルスに感染したEXEファイルをダウンロードし、ウイルスチェックをかけず、実行して攻撃を受ける」のと何が違うのだろうか、と思います。後者はWindowsのEXE実行機能の脆弱性なのでしょうか？
ついでに瑣末事ではありますが、
窓の杜の記事には、とありますね。情報元ページには悪用可能で未対処な脆弱性がたくさん載っていたわけですから、大手メディアとしては妥当な判断ではあると思います。批判を受けてこっそり追記、などではなく最初からあったはずです。メール版にも載っていますし。
まあ、今更であることは変わり在りませんが。また、一つのウェブサイトに書いてあったことを鵜呑みにしていきなり記事にしてしまうのもどうかと……。それこそ、shoda T.さんのような「専門家」に相談して裏を取ってからのほうがよかったのでは、と思いますね。
以下オフトピ御免……。
きっとshoda T.さんが黙っちゃいないだろう、と思っていました。次回の某ニュースのネタはこれかな（笑）。
-May the sakura-cards be with you.-
Re:窓の杜の情報元は (スコア:2, すばらしい洞察)
Re:窓の杜の情報元は (スコア:1)
まず、今回脆弱性とされている問題は、書庫内の相対パス指定によりユーザーが指定したフォルダの上位フォルダにファイルが展開されることがあるのが原因、という点を確認しておきます。（そういえばこの前提を知らないと成り立たない議論かも……窓の杜の記事にはないですね）
「指定フォルダ」の定義によります。冒頭に述べたように、今回問題になっているような書庫では、「ユーザーが指定したフォルダ＋書庫内にある上位に向けた相対パス」を元にファイルの展開先が決められます。
それを脆弱性と言うならば、書庫内にサブフォルダがあった場合に、展開先にサブフォルダが作成されるのも、「指定フォルダ」ではないという意味では同様であり脆弱性となりますが、その理解でよろしいですか？ 私は違うと思います。以上のことから私は「指定フォルダ」というのは「ユーザーが指定したフォルダ＋書庫内で指定されているフォルダの合算」と理解しています。
もし、「書庫内のフォルダ構成を無視して展開する」オプションがあるアーカイバで、オプションONでもこの相対パス指定が効いてしまうようなら、それは当然脆弱性でしょうけれど。
（ついでに、たとえ脆弱性だったとしても、仕様通りの動作なので「バグ」ではないですが、別の話になるので割愛。）
脆弱性であるかどうかを決める基準に、「多くの人が認識している」という要素はあるのでしょうか？ 先にMatsuTakeさんが引かれたe-Wordsにもそのような定義はないようですが。
それとも、どちらも脆弱性であるが、多くの人が認識していない脆弱性のほうがより危険である、という主張でしょうか。それでしたら（そのこと自体には）同意します。
-May the sakura-cards be with you.-
Re:窓の杜の情報元は (スコア:2)
Re:窓の杜の情報元は (スコア:1)
サブフォルダが作成されることにより、ディレクトリエントリがディスク上に確保されることで、ユーザが意図しないディスク領域を利用されてしまう脆弱性……とかいう言い方をしたら、攻撃を受けている形になりますか?
ユーザの意図しない挙動が発生すること、というのが最も重要なのではないでしょうか。
Re:窓の杜の情報元は (スコア:0)
BMP bombレベルになれば立派にDoS攻撃を受ける脆弱性だと思いますが、ディスク領域が使われること自体を「意図しない」と言うのはかなり苦しいと思います。サブフォルダだけでそんなに大量のディスク領域が消費されるんですか?
意図しない電力が消費される脆弱性。対策: 電源を入れないこと
Re:窓の杜の情報元は (スコア:1)
塵も積もれば邪魔となるものですから。
それと、.lzh や .zip などを利用可能な全てのプラットフォームにおいて発生しうる問題という事を考えると、少し前の WinCE 機などでは、1byte でも削りたいとか言うことになると思いますが。
書庫上では数バイト程度のディレクトリエントリ情報が、ディスク上に展開されると数百バイトから数キロバイトの範囲 (クラスタサイズ等に依存) に増加するわけで、dir bomb も可能と言えるものでしょう。
これを「はぁ?」と思うのであれば、書庫展開により予期しない場所にファイルを作成されうる問題も、同程度に「はぁ?」だと思いますよ。
Re:窓の杜の情報元は (スコア:1)
自分が直接指定したフォルダ(とその下位フォルダ)「のほかに」展開先が有り得るってことを
知ってる人がどれだけ居るか、って話でしょうかね。
つまり、
>「確認しないのが悪いじゃん」としか言いようがない気がするのですが……。
「確認すべき項目」が存在するのを、彼ら(誰?)は、知らないわけですよ。
>Explzhなどの一覧表示式アーカイバ
個人的には、こういう奴でないと安心できないタチですね。
いきなり実Filesystemに展開するんじゃなく、ワンクッションある奴が、落ち着く。
そんなわけでtar tfvは必須。
そして、そのクッション(?)「を」実フォルダへDragDropできるっていう点(俺的に言えばObject指向っぽさ)が嬉しい。
その点ではExplzh方式はtar tfvより強力ですね。tfvの出力はいちいち監視しなければ今回の問題を回避できませんが、
クッション「を」掴んで操作する操作体系だと、監視もへったくれもなく、対象物(のイメージ)が正にそこにあるんだから、
ハマりようがない。
こういう点が、GUIソフトの本来のメリットである「説明書読まなくてもいい」っていう点なんですよね。
そこにある「それ」を操作すればいいんだから、「それ」を間違いなく(他と取り違えずに)手にする手段を
悩む必要がないし、
「それ」がそこにあるんだから、それを(取りこぼさずに)見つける手段も
悩む必要がない。
「それ」の数が多くなりすぎたら、アイコン相手の手作業じゃ手におえなくて、CUIが恋しくなったりするわけですが、
何が起きるか全て判っている人にとってはそれでOKでしょうけど、
判ってなくて探索型の振る舞いをせざるを得ない人にとっては、
「それ」が適切なタイミングで目の前に立ち表れるUIのほうが、ずっと「安全」でしょうね。
モノを、適切な単位で1つに固めた状態にして、それを人(ユーザなりプログラマなり)に見せる、
そうすれば人間が直感的に間違いにくくなる、
っていうのがObject指向の肝なんだよね。＃ちなみに隠蔽や継承は2次的なものです。
>脆弱性の悪用拡大を防止する目的で、情報元などの詳細に関しては割愛する。
どうなんだろう？
こんな「簡単に」実施できてしまうアタック方法は、
ちょっとでも悪意のある奴はホイホイやっちゃうだろうし、
原理が自明といってもいいくらいに単純明快だから、情報元を紹介(照会)するまでもなく、
その杜記事だけで充分に「悪用拡大」に貢献しちゃうんじゃないかな。
つまり、「もう遅いよ…」って奴。
Re:窓の杜の情報元は (スコア:1)
まぁ、「情報元などの詳細に関しては割愛する」ってのは読んだんですが、そもそも何の情報源かもわからんし（笑
のっけから「確認した」のインパクトは大きいかと。
とりあえず前からの懸案でもあったので、タイミング良く UNLHA32.DLL は対応版出ましたが・・・
もとよりＭｉｃｃｏさんはどっちかというと否定派なので、実際にはアプリ側が対応しないとあまり意味ないかも（笑
>>きっとshoda T.さんが黙っちゃいないだろう、と思っていました。次回の某ニュースのネタはこれかな（笑）。
黙ってないと言うか、なんだかなぁ感が（笑
某ニュースのネタですか。これはニュースにはならないですね。全然新しくもないし :-)
ま、でも何か書かないと許してくれない人が何人かいそう（爆