さまざまなソフトウェアでのアーカイブファイル展開処理に脆弱性、任意コードの実行を許す可能性 32
ストーリー by hylom
広範囲に影響 部門より
広範囲に影響 部門より
あるAnonymous Coward曰く、
イギリスのセキュリティベンダーSnykが、ZIPなどのアーカイブファイルの展開時における脆弱性について注意喚起を行っている（発表された情報、JPCERT/CC、窓の杜）。
この脆弱性は「Zip Slip」と名付けられており、アーカイブ内に格納されているファイルのパスを相対パスに設定することで、利用者の意図とは異なる場所にファイルを展開させるというもののようだ。アーカイブファイルを操作するツールの一部ではこういった相対パスで指定されたファイルを検証せずにその場所に展開するものがあり、こういったツールで問題が発生するという。また、こういった問題はZIP以外のファイル形式でも発生する可能性があるという。
すでに複数のベンダーに非公開で報告が行われているとのことで、その多くで対策が実施されているという。影響を受ける製品やそのバージョン、対策状況などは“GitHub”のプロジェクトページで公開されている。
この問題はプログラマ向け情報サイト「StackOverflow」などで公開されている脆弱性のあるサンプルコードがそのまま使われることで拡散したともされている。
そこは我々が14年前に通った道だ (スコア:1)
https://forest.watch.impress.co.jp/article/2004/07/30/arcsecurity.html [impress.co.jp]
Re:そこは我々が14年前に通った道だ (スコア:1)
残念、そこは我々が27年前に通った道だ。
http://phrack.org/issues/34/5.html#article [phrack.org]
#仕様が原因だから仕方がない面もある
Re: (スコア:0)
PDFにも任意コマンドを実行できる仕様とかあるけどそれはもう仕様のほうが時代に合っていないから曲げざるを得ない
Re: (スコア:0)
関連リンクに無いけど、スラドでも記事になってたのなそれ。
多くの解凍ソフトに指定外の場所に解凍してしまう脆弱性 [srad.jp]
どうみても同じネタだよなぁ。中の人が世代交代して脆弱性も繰り返されるのか（しみじみ
Re: (スコア:0)
解凍に限らず、どこの誰が指定したのやら分からないパス名を扱うソフトを書くときは、よくよく注意して実装した上、ちゃんとテストしないと駄目な定番のポイントだよね。
Re: (スコア:0)
△ どこの誰が指定したのやら分からないパス名を扱う
○ どこの誰が指定したのやら分からない入力を扱う
Re:そこは我々が14年前に通った道だ (スコア:2)
△ どこの誰が指定したのやら分からない入力を扱う
◯ 入力を扱う
Re: (スコア:0)
セキュリティ界隈がイマイチ反応が鈍いと思ってら
同じ鉄を踏んだだけだったのかw
近代言語向けに再実装した過程で再度出現したのは面白い事例だな
横の情報共有は多いけど、縦の情報共有が薄いという証拠になりそう
Re: (スコア:0)
だって例えば tar 何てわざわざ警告出すって言うか、デフォルトで勝手にパスを書き換えるくらい解凍するときのパスでやらかした人は多いですから
他の人も言ってますが飽きてるんですよ
# tar: Removing leading `/' from member names
Re: (スコア:0)
tar 何て
Re: (スコア:0)
×同じ鉄
○同じ轍
Re: (スコア:0)
アメリカ大陸はコロンブスが発見するまで存在しなかったんだ。OK?
便利な機能 (スコア:0)
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
Re:便利な機能 (スコア:1)
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
いやいや今回のは
LZH時代でも脆弱性扱いされてた
懐かしのネタだから
実装する人も代替わりして久しく
歴史は繰り返されるというだけの話
管理権限無いと書き込めないディレクトリがある分
危険度は当時よりもわずかに軽いかも
Re: (スコア:0)
当時から脆弱性扱いして欲しくなかったのですが
Re: (スコア:0)
元コメはきっと「..」で親ディレクトリが辿れる機能がけしからん、禁止だ、って方向には行って欲しくないなぁ、って意味だよ。
「..」とか余計な機能作んなよ、という理不尽で的外れな怒りは自分も覚えがある。
簡易ウェブサーバみたいなのを作ってて、リクエストされた対象が、公開対象として指定したディレクトリから
はみ出してるときには確実に蹴れるようなチェックってどうやったら完璧に出来るんだよ、と悩みつつ。
「..」を含むリクエストを邪悪なリクエストとして蹴れば良いのか、「/」が複数続いてるとルートになるんだっけ、とか色々考えた挙げ句、
ファイルのパスを作り上げてから、公開対象がその祖先になってるか調べる方法に落ち着いた。
Re:便利な機能 (スコア:1)
シンボリックリンクはどうしました?
参考 [github.io]
Re: (スコア:0)
面倒くさかったので諦めた。それはファイルを置くときに気を付ければ済むことなので。
極論すると、「公開ディレクトリの下にヤバいとこへのリンクを置いたり、ヤバいものをマウントしたりしない」ってのは、
「公開ディレクトリの下に重要なファイルを置かない」というポリシーに含まれるし。
シンボリックリンクとマウントと、その他、調べてないけど、他にもあるならそれらも含めて、今、考えられるあらゆることに対応しておけば、
今後作られるどんなOSや環境でも大丈夫、という保証もないし。
Windowsでいつの間にやら増えたVirtualStore機能みたいに、何か新たな仕組みがいつの間にやら増えるかも知れないし。
一部だけ対応して安心なつもりになっちゃうのも危ないかな、とかあれこれ自分に言い訳をして。
Re:便利な機能 (スコア:1)
面倒くさかったので諦めた。それはファイルを置くときに気を付ければ済むことなので。
そのノウハウは重要だし、なんらかドキュメント化されるべきものだと思うな。
Re: (スコア:0)
うん。どこかのセキュリティの専門の機関が、現状ではこれだけ気を付ければOK、
と太鼓判を押すようなガイドラインを公開してアップデートし続けておいて欲しい。
スーパールート(オフトピ) (スコア:0)
/でルートディレクトリ
//でスーパールート。次に来るのは「ホスト名」
大元はRFS(Remote File System)
URIの最初(プロトコルハンドラだっけ？の次)も発想元はこれだったはず
Re:スーパールート(オフトピ) (スコア:1)
Remote File Sharing [wikipedia.org]ね。
# Newcastle Connection [doi.org]みたいなやり方… /../host/dir/file と、どっちがマシなんだろう？
Re: (スコア:0)
スクリプト書いてるとディレクトリが格納された変数の最後に / が付いてるか微妙なときに
/が連続しても無視するのを利用してとりあえず ${hoge}/fuga.dat とか書くことあるから
個人的には混乱することが……
Re: (スコア:0)
記事が脆弱性としてるのは、例えば、指定したディレクトリに展開するの機能なのにそういうアーカイブが許可されている、というようなものでは？
それ自体が解凍ソフトでも無ければ、少なくとも無制限にはこの機能は不要でしょうから、ユーザー入力+eval()=脆弱性みたいなことだと思います。
Re: (スコア:0)
コマンドラインとかではデフォルトで相対パス解決が有効になっててもいいけど、ソースコード上では明示的に関数を呼んでやらせない限り勝手なことはしないようにして欲しかったな
短い関数名にしておけば毎回書くのも大した手間ではないだろうに、無能な働き者が余計な処理を仕込んだせいで、手間が省けるより「お前を消す方法」を探す手間がかかることの方が多くなってしまってる
Re: (スコア:0)
同フォルダのDLLを読ませる機能をいつ無条件で禁止した？
Re: (スコア:0)
規定値
投稿されたコメントから推察される (スコア:0)
スラドの超高齢化であった
昔々 (スコア:0)
/etcをフルパスでtarボールにして持って帰ってきた同僚がいたなあ。
Re: (スコア:0)
chrootすりゃいいだろ
Re: (スコア:0)
そういうコマンドあること知らないんだろ
Re: (スコア:0)
だからGNU tarを使えとあれほど… …