アカウント名:
パスワード:
私も、これを脆弱性と呼ぶのは違和感がありました。ただ、
厳密な言い方をするなら、脆弱性ではなく、仕様範囲内であっても使用者の意図と異なることが起こりうることをどう捉えるか、と言う問題ですね。
#598858でも書かれているように、仕様自体が脆弱性を内包していることもあり得ます。ですから、仕様通りの動作だから脆弱性ではない、ということはないかと思います。
どちらかと言えば私が気にしているのは、本当にこれは「ユーザーの意図せず行われる操作」なのか？ということです。
Explzhなどの一覧表示式アーカイバで件の書庫を開
一方、問題になりそうなのは、「アイコンにドラッグだけで一発解凍」系ですが、これはあくまで、「書庫内を確認して解凍操作をする」という手順を省略しているに過ぎません。ユーザーはこのタイプのアーカイバを選択することで、自分の意志により内容確認の権利（というのは大げさかもしれませんが）を放棄していると言えます。
ソフトの説明に、「指定フォルダに展開する」と書かれているのであれば、指定していないフォルダに展開するのは「バグ」かつ「脆弱性」です。
実際に『脆弱性』を利用した書庫が
まず、今回脆弱性とされている問題は、書庫内の相対パス指定によりユーザーが指定したフォルダの上位フォルダにファイルが展開されることがあるのが原因、という点を確認しておきます。（そういえばこの前提を知らないと成り立たない議論かも……窓の杜の記事にはないですね）
「指定フォルダ」の定義によります。冒頭に述べたように、今回問題になっているような書庫では、「ユーザーが指定したフォルダ＋書庫内にある上位に向けた相対パス」を元にファイルの展開先が決められます。
それを脆弱性と言うならば、書庫内にサブフォルダがあった場合に、展開先にサブフォルダが作成されるのも、「指定フォルダ」ではないという意味では同様であり脆弱性となりますが、その理解でよろしいですか？ 私は違うと思います。以上のことから私は「指定フォルダ」というのは「ユーザーが指定したフォルダ＋書庫内で指定されているフォルダの合算」と理解しています。
もし、「書庫内のフォルダ構成を無視して展開する」オプションがあるアーカイバで、オプション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などの一覧表示式アーカイバで件の書庫を開
-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 も可能と言えるものでしょう。
これを「はぁ?」と思うのであれば、書庫展開により予期しない場所にファイルを作成されうる問題も、同程度に「はぁ?」だと思いますよ。