多くの解凍ソフトに指定外の場所に解凍してしまう脆弱性 103
ストーリー by Oliver
いかなる入力も信用できない 部門より
いかなる入力も信用できない 部門より
coco-natade 曰く、 "今日は午前様の私、就寝前にちょっとWebを覗いてみて驚いた。「窓の杜」の記事。多くの解凍ソフトに、指定外の場所へファイルが解凍される脆弱性(というより「危険性」か？)の存在を、窓の杜編集部が確認。具体的には、特殊な方法で作成された書庫ファイルを解凍すると、ユーザー指定のフォルダのあるドライブの別フォルダにファイルが展開されてしまうとい。 使い方によっては、スタートアップフォルダにウイルスやスパイウェアを送り込んでおくことも可能。現在の対処法は、この脆弱性を修正した「Lhasa(v0.18)」などで解凍するか、次善の策として重要度の低いドライブの任意フォルダを解凍先に指定すること。"
関連記事 (スコア:2, 参考になる)
また、各種アプリの対応状況は圧縮ファイル解凍の脆弱性 [matcha139.org]よりどうぞ。
distinguish full Path names (スコア:1, 興味深い)
解凍する時に中身なんて確認せずに解凍して、
普通の相対パス指定のファイル群の中に1ファイルだけスタートアップへの絶対指定を紛れ込ませておいても気づかないんじゃないでしょうか？
逆にpオプションがセキュリティホールにならないなら、
相対指定でおかしなパスが指定されていても、解凍時にちゃんと
中身の一覧を確認してる人なら気づくので、今回の件も
セキュリティホールにはならないと思うのですが。
悪意のある人がそんなことするか？ (スコア:1)
＞圧縮ファイルを解凍すると
悪意のある人ならそんな面倒なことしないで、
実行ファイルに仕掛けを施すと思うのですが。
Re:悪意のある人がそんなことするか？ (スコア:1)
逆に言えば「そんな面倒なことしないだろう」と安心してる人も狙い撃ちできるステキな攻撃方法なわけです。
想定できる攻撃は想定しておきましょー。
Re:悪意のある人がそんなことするか？ (スコア:1, 興味深い)
どっちが面倒なのかよく考えてみました？
ひそかにファイルをしのばせるのは、技術力がそれほどなくてもできてしまいます。
また、忍ばせられるのは実行ファイルとは限らなくて、設定ファイルだったりするわけです。
たとえば、Winnyの設定ファイルをいじられて、Cドライブすべてが、共有されてしまう・・・ってことが簡単にできてしまいます。
気をつけましょう!
Re:悪意のある人がそんなことするか？ (スコア:1, すばらしい洞察)
ウィルスチェックに引っかかる可能性はまずありません。
Re:悪意のある人がそんなことするか？ (スコア:1, 参考になる)
さらに、窓の杜記事やオリジナルの報告サイトの文書にもあるように、「スタートアップ」フォルダに展開すると実行されてしまうことが問題なのです。
要は、悪意ある人は「いかにして悪さをするプログラムを実行させるか」に心血を注ぐわけです。
これは、（少し今回の欠陥とはずれますが）実行ファイルに限らず、バッファオーバランの欠陥を突いてメモリ上に悪意あるコードをロードさせて実行させようとするウイルスのことなどを考えていただけるといいかと。
悪意ある人も大変なのです
Re:悪意のある人がそんなことするか？ (スコア:1)
あまりにも重いんで、その機能をOFFにしてしまいたい衝動に日々駆られてます。
＃非力な機械にNAVは無茶なのだそうなのでG7
＃ディスク全件チェックに一昼夜かかっちまった(T_T)
＃つまり「毎日チェック」は不可能なわけで。
zipは怖くてOFFれませんが、
jarくらいなら良いかな？と、ついつい思ってしまう。
＃もちろんこれは「間違った安心感」なので、良い子は真似しないようにG7
「(普及してる)ウイルスに、そもそも感染しないシステム」が欲しい、と思うのは
エコロジー(CPU電気代の無駄を省く)の観点からも、正しい判断なような気がしてなりません。
Re:悪意のある人がそんなことするか？ (スコア:1)
ところで余談ですが、
Mailソフトの中(?)で「複数の」Mailをくっつけて保管してるファイルは、
どう扱えばいいんでしょう？
ウイルス入りMailを受け取ると、Mailソフトは(恐らく)それをMail保管ファイルに追記するわけですけど、
その際、ウイルスチェッカが介入してきます。
が、ウイルス入りファイルの削除には失敗するんですよね。
(想像ですが)そりゃ当然です。なんせ、追記された問題の部分を綺麗に切り離す手段が、(公開された形としては)存在しないのだから。
このへんは、追記の方法も分離の方法も同じように公開されてる汎用アーカイブソフトとは違うところなんでしょうね。
その結果なにが起きるかってーと、同じ保管ファイルに納められていたファイル全部を巻き添えにして
ファイルへのアクセスが遮断されちゃうんです。
つまり、今届いた重要なMailとウイルス入りMailが、いっしょくたにアクセス遮断されちゃう(T_T)
ウイルス監視をいったんOFFして、Mailを切り分けて…なんてことをしてます。
うーん。こういうもんなんでしょうか？？
Re:悪意のある人がそんなことするか？ (スコア:1)
未だに仕組みをよく理解してないですが…
「添付ファイルつきの」Mailなら、今でも始末するようにしてるんですが、
「Content-Typeがtext/plainでない」ってのは、添付どころか本文自体が非Textだ、という意味でしたっけか？
そういや、添付つきの奴を始末してる割には、HTML「つき」の奴は無くならないなぁ、と思っていたところです。ぉぃぉぃ。
…俺、もしかして、使用中のMailソフトの「添付ファイル」表示欄に、だまされてましたかね？？(^^;
＃「見かけ上のModel」を、実際のModelと大きく異なるかたちでViewに表示するソフトは、痛いと思っているのでG7
＃ユーザには結局、ありのままを見せたほうがいいんだと思う。
＃結局は、誤解に基づいた思考をするお客さんが、クレーマー(隣接Story参照)になる確率が高いのだろうから、
＃中身に対しての、(詳細ではないにせよ)それなりに正確な理解を、ユーザさんにも持っていてもらいたいし、
＃作り手もそう仕向けるべきなんだよな。
>30個くらいあった振り分け条件の一番上に，
やっぱり、30個くらい条件を指定できるソフトでないと、
使い物にならんと見なすべき…なのかな…
こっちのは、3つくらいしかなかったような気が(T_T)
Re:悪意のある人がそんなことするか？ (スコア:1, 参考になる)
Re:悪意のある人がそんなことするか？ (スコア:1)
つまるところ (スコア:1)
IDENTIFICATION DIVISION.
AUTHOR YUKI-KUN.
Re:つまるところ (スコア:1)
書庫展開するコマンドを渡す前に、その書庫に対して
CheckArchive する
OpenArchive する
FindFirst して１個目の書庫内ファイル名を取得、変なパスがないかチェック
FindNext して２個目～最後までの書庫内ファイル名を取得、変なパスがないかチェック
CloseArchive する
この過程で変なパスがあれば解凍阻止/事前警告といった対応をする、とか。
# ほかの対策があれば参考にしたいのでID。
再現せず、というのはどういう意味？ (スコア:1)
//窓の杜のリストの中ではWinRARとLhasaしか使ったことないや。
相対パスや絶対パスを実際に使ってる人が困る (スコア:1, 興味深い)
ファイルを解凍できなくなったり、絶対パスでの解凍が出来なくなったりしたら元々そういった機能を便利に使っていた人が困るんじゃないかな。
一番最初に脆弱性とか煽って無理に対策させた人の顔が見てみたいな。
Re:相対パスや絶対パスを実際に使ってる人が困る (スコア:1)
・相対パスや絶対パスが利用できなくなる事のデメリット
と
・相対パスや絶対パスによりウィルスなどを仕込まれるデメリット
を天秤にかけたとき、どちらがより重大か、という問題ではないかと。後者の方が大きいという認識をしている人がが多いため、にここまで大きな問題になったわけで。
というか純粋に疑問なんですが、絶対パスはともかく、..でそこより上のディレクトリへ展開するような機能って、そんなに多くの事例で使われているのでしょうか？
あとは、解凍する時に気をつければいいので脆弱性ではない、という考えの人が少ないながらもいる、ということに少し驚いていたり。
Re:相対パスや絶対パスを実際に使ってる人が困る (スコア:1, すばらしい洞察)
商用ネットの頃から同じ問題があったはずなのに。
やっぱり脆弱性って言葉が大好きな一部の人が煽ってるだけにしか見えません。
Re:相対パスや絶対パスを実際に使ってる人が困る (スコア:1, 参考になる)
脆弱性でないならないでかまいませんが、被害が出るであろうことは想定できます。
ちょっとしたウィルスと絡ませれば無差別にメールを送ったり特定のサイトにアタックを掛けたりできるでしょう。
かつてはネットの世界も紳士協定が良く守られていた社会だったのでしょう。
でも今はそうも言ってられない状況になってしまったってことでしょう。
また、ブローバンドの普及で誰もが簡単に24時間接続できるような状況です。
ウィルスによる被害もナローバンドの時代とは比べものになりません。
かつては大きな問題でなかったからと言って今（あるいは今後）も大きな問題にならないとは限りません。
＃絶対パスで解凍できる圧縮ファイルが作れること自体知らないことだったので
＃自分の意図しない場所にファイルが解凍されると聞いて本気で驚きましたよ。
Re:相対パスや絶対パスを実際に使ってる人が困る (スコア:1)
いずれにせよ、問題が明るみになった以上、話題にするのは悪くないと思いますが。煽るというと、何か周知(して改善を求める事)が悪い事のように聞こえますが。
コマンドラインの場合 (スコア:1)
入れ替えた時点でそれ使ってるmakefileやスクリプトを残さず全部書き換えないと暴走の原因になるとか。
数が多いと面倒なのねん。
grepでン百ン千と出てきた日にゃ一気に萎えますです。
--
Ath'r'onならfloatあたりに自信が持てます
Re:お手軽物に集中? (スコア:2, 興味深い)
ですので、ARJやRARな書庫を扱わないとしても、解凍しようと考えた時には結局のところ解凍ソフトを拾ってくるので、使わない解凍機能を削除しておいても結果は同じでしょう。
まぁ、削除しておかないことによって、穴が残っているバージョンを使ってしまう可能性が高くなることを考えると、削除しておいたほうがいいかもね…とは言えますが…。
それ以外の点では一緒じゃないかと。
Re:窓の杜の情報元は (スコア:5, 参考になる)
何もかも脆弱性の一言で片付けてしまうと、本当の危険が隠れてしまいそうな気がするので、こういう情報を流す人は、危険度のランク付けをして、出来れば言葉も変えてほしいなぁと思いますね。
そもそも問題とされていることは、かなり以前から directory traversal問題として議論されたことですね。なんで今更、と言う感がぬぐえないです。
特に窓の杜の記事は、まるで自分たちが「発見」したみたいな書き方で非常に不愉快ですね。
厳密な言い方をするなら、脆弱性ではなく、仕様範囲内であっても使用者の意図と異なることが起こりうることをどう捉えるか、と言う問題ですね。
絶対パスや ..\ なパスが格納されていた場合に、解凍者が指定したパスとは異なる場所に解凍されたとしても、それは本来、書庫作成者が意図したことであり、ソフトも意図どおりに解凍してるわけです。
いわゆる脆弱性は、バグによる意図しない動作が、たまたま危険な動作を起こしうると言う点にあるとすれば、directory traversal問題はバグとは全く関係ないわけで、同じ脆弱性と言う言葉で片付けるのは違和感ありますね。
それより、そこまで言うなら、世のインストーラや自己解凍書庫はどうなんだって言いたい人も多いはず。
だからと言って全く問題ないと言うのではありません。
directory traversal問題はあちこちで議論され、一応結論は出てると思うんですね。
解凍者が意図したフォルダ以外（直下を除く）に解凍される場合にどうするか。警告を出すとか、禁止するとか、設定で選択出来るようにするとか、対応はそれぞれですが、いずれは対策が出揃うと思います。緊急性はそれほどないと思われるので、個々のソフト（やライブラリ）により進捗状況はさまざまですが。
ただ、解凍出来なくした（？）ソフトを推奨すると言うもの何か違和感あるのですが・・・最近存在感が落ちてきた Lhasa への援護射撃？なんてのは冗談ですが、特定ソフトを「推奨する」という言い方は気になります（爆
Re:窓の杜の情報元は (スコア:2, すばらしい洞察)
Re:窓の杜の情報元は (スコア:1)
論点は少しずれるかもしれませんが、電子レンジの設計者は明らかにネコを乾燥させるようなことは想定してないわけですが、そこまでも「仕様のバグ」と言ったら言い過ぎですよね。それでも、現実には「ネコを乾燥するのに使用してはいけない」と説明書に書かざるを得ないわけですね（笑
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)
自分が直接指定したフォルダ(とその下位フォルダ)「のほかに」展開先が有り得るってことを
知ってる人がどれだけ居るか、って話でしょうかね。
つまり、
>「確認しないのが悪いじゃん」としか言いようがない気がするのですが……。
「確認すべき項目」が存在するのを、彼ら(誰?)は、知らないわけですよ。
>Explzhなどの一覧表示式アーカイバ
個人的には、こういう奴でないと安心できないタチですね。
いきなり実Filesystemに展開するんじゃなく、ワンクッションある奴が、落ち着く。
そんなわけでtar tfvは必須。
そして、そのクッション(?)「を」実フォルダへDragDropできるっていう点(俺的に言えばObject指向っぽさ)が嬉しい。
その点ではExplzh方式はtar tfvより強力ですね。tfvの出力はいちいち監視しなければ今回の問題を回避できませんが、
クッション「を」掴んで操作する操作体系だと、監視もへったくれもなく、対象物(のイメージ)が正にそこにあるんだから、
ハマりようがない。
こういう点が、GUIソフトの本来のメリットである「説明書読まなくてもいい」っていう点なんですよね。
そこにある「それ」を操作すればいいんだから、「それ」を間違いなく(他と取り違えずに)手にする手段を
悩む必要がないし、
「それ」がそこにあるんだから、それを(取りこぼさずに)見つける手段も
悩む必要がない。
「それ」の数が多くなりすぎたら、アイコン相手の手作業じゃ手におえなくて、CUIが恋しくなったりするわけですが、
何が起きるか全て判っている人にとってはそれでOKでしょうけど、
判ってなくて探索型の振る舞いをせざるを得ない人にとっては、
「それ」が適切なタイミングで目の前に立ち表れるUIのほうが、ずっと「安全」でしょうね。
モノを、適切な単位で1つに固めた状態にして、それを人(ユーザなりプログラマなり)に見せる、
そうすれば人間が直感的に間違いにくくなる、
っていうのがObject指向の肝なんだよね。＃ちなみに隠蔽や継承は2次的なものです。
>脆弱性の悪用拡大を防止する目的で、情報元などの詳細に関しては割愛する。
どうなんだろう？
こんな「簡単に」実施できてしまうアタック方法は、
ちょっとでも悪意のある奴はホイホイやっちゃうだろうし、
原理が自明といってもいいくらいに単純明快だから、情報元を紹介(照会)するまでもなく、
その杜記事だけで充分に「悪用拡大」に貢献しちゃうんじゃないかな。
つまり、「もう遅いよ…」って奴。
10月発売のハッカージャパンでも、 (スコア:1)
#さすがに8月売りの号には、もう間に合わないと思うが。
/* Kachou Utumi
I'm Not Rich... */
Re:許容範囲だと思うのだが (スコア:2, 参考になる)
Attn: Windows 98/98SE/Me/XP Only
Re:tar (スコア:1)
＃フリー(OpenSource)ソフトが信用できないと言うくせに、
＃その一方で、それより遥かにヘボ(藁)な自社ソフトは平気で動かす、ってのが解せないのでG7
Re:tar (スコア:2, 参考になる)
Re:「解凍」って表現 (スコア:2, 興味深い)
問題なっしんぐ。
ほかの圧縮形式に使うのは確かにヘンだけどね。
Re:「解凍」って表現 (スコア:1)
LHAはfreezeだけどmeltではなかったよーな。 オプションでeやxなのはexpandだからです。
日本語ではご指摘の通りなのですが、英語では完全に対応していない、ってことですね。
Re:「解凍」って表現 (スコア:1)
今、LHA version 2.53 (DOS版)で確認しましたが、表示するメッセージは
Melting ...←展開中の表示
Melted ←展開後の表示
ってなってますよ。また、圧縮時の表示は
Freezing ...←圧縮中の表示
=> ←圧縮後の表示
となります。
> オプションでeやxなのはexpandだからです
オプション無しで起動したときの usage では
a: ファイルを追加 u: 新ファイルを追加 m: 新ファイルを移動
f: ファイルを更新 d: ファイルの削除 p: ファイルの閲覧
e: ファイルを復元 x: ディレクトリ付きでファイルを復元
ってなってます。
圧縮ソフトの機能としては、compress/uncompress の代わりに 凍結(freeze)/解凍(melt) という言葉を使うけど、
アーカイバの機能としては、add/extract ということなんでしょう。
Re:「解凍」って表現 (スコア:1)
//窓の杜の昔の事件を憶えている人いる？
Re:「解凍」って表現 (スコア:2, 参考になる)
ところで，昔の事件というとどれのことでしょうか。
Re:「解凍」って表現 (スコア:1)
CD-Rにデータを書くときも「焼く」って言いますし・・・
「焼く」 => "Burn"って言葉を使いますよね。
Re:「解凍」って表現 (スコア:1)
そうなんですか?
gzip/bzip2のmanを見ても expand って書いてあるし, M$のサイトにも How To Use the COMPRESS, COMPACT, and EXPAND Commands to Compress and Expand Files and Folders in Windows 2000 [microsoft.com]とあるように compress(圧縮)と対になってるのはexpand(伸長)だと思うんですが.
『解凍』っていうのは 日本人が作成したツールであるLHa [chienowa.co.jp] で使われていたため日本では解凍という言葉になってしまったと聞いたことがあるのですが…….
聞いただけであってsourceもへったくれもないのですが.
Hacker/Cracker, Homepage/Webpage に拘る人の多い /.-Jで解凍がおざなりなのがちょびっと意外ですねぇ.
tar とか使っていると 伸長と展開って別物だって意識することもありますし.
Re:「解凍」って表現 (スコア:1)
Re:「解凍」って表現 (スコア:1)
さらにまえの arc, pkxarc あたりになると記憶がない。
Re:「解凍」って表現 (スコア:1)
Re:「解凍」って表現 (スコア:1)
Re:tarアーカイブ (スコア:2, すばらしい洞察)
つ chroot
Re:tarアーカイブ (スコア:1)
フルパスはヤバイけど、相対パスは(上位に遡るパスでない限り)今回言うような意味でのヤバさは無い、のではないかと。
ま、下方向の相対であっても、その位置に「上書きされることをユーザが意図してない」ファイルが有ったら、同じことなんだけどね(^^;
また、一般ユーザであっても、「上書きされることをユーザが意図してない」ファイルは幾らでも有り得るわけなんだけど。
そういや先日 tar cfv hoge.tar ～／ｈｏｇｅｈｏｇｅとか書いて、ハマりました(^^;
～がフルパスに(shellにて)解釈されちゃうんですよね。
一般ユーザで良かったです。「良かった」といっても比較的ですけどね。
Re:tarアーカイブ (スコア:2, 興味深い)
今回問題になっているのはまさに「上位に遡る相対パス指定で格納されたファイル」を展開させることで、悪意ある攻撃が可能になる、ということなのですが…
で、本題。 GNU tar であれば、
作成時・展開時のどちらの場合でも、
・ファイル名が / で始まる場合
・ファイル名に .. が含まれる場合
はエラーになります。
--absolute-names オプションで強制的に作成/展開も可能ですが…
というわけで、今時だと普通は問題にはならないんじゃないでしょうか。
#GNU tar じゃない tar が入っているシステムだったらヤバイとは思いますが…
Re:tarアーカイブ (スコア:1)
>#GNU tar じゃない tar が入っているシステムだったらヤバイとは思いますが…
「フリーソフトを入れちゃいけない」計算機だと、ヤバイですぅ…
＃「標準tarにセキュリティ穴がある！」とかいって上司を煽るという手もありますが(^^;
Re:tarアーカイブ (スコア:1)
との事で、「荒らし」となっているが、
そんな感じの事をやらかした同僚がいた。
「アホンダラ！」
と言われただけで済んだ。（復旧作業は済まないが・・・）
マジに怒らせると、言葉はシンプルになりますね。