10MBのファイルが281TBに膨らむ新型「非再帰的ZIP爆弾」 80
ストーリー by hylom
増えるファイル 部門より
増えるファイル 部門より
Anonymous Coward曰く、
プログラマー兼エンジニアのDavid Fifield氏が、たった10MBのサイズにも関わらず、展開すると281TBにまで爆発する新しいタイプの「ZIP爆弾」を発表した。
ZIP爆弾は、そのファイル自体は小さいにもかかわらず、展開すると巨大なファイルになるように細工をしたZIPファイルの俗称。小さなファイルを巨大なファイルとして展開させることによりPCのCPU、メモリ、ディスク容量といったリソースを奪うことができる。
通常のZIP爆弾は内側のZIPファイルの中にさらにZIPファイルを作るという再帰的手法で作られているが、それゆえに多くのアンチウイルスソフトで対策されている。Fifield氏が考案した「非再帰的ZIP爆弾」は、再帰のない単一層でより密集したファイルを作成できるのが特徴。
展開後のファイルサイズこそ高効率で作られた再帰的ZIP爆弾にかなわないものの、それでも展開後のサイズを2800万倍に膨らませることができるという。さらに、ZIP64形式を用いることで46MBのファイルを9800万倍の4.5PBにすることも可能だとしている（Vice、GIGAZINE、Slashdot）。
多くのアンチウイルスソフトは対策済み (スコア:5, 参考になる)
しっかりと検証したわけじゃないと昔の記憶なので曖昧ですが、多くのアンチウイルスソフトやクラウドストレージは対策済みですよ。
DTMとかで長時間無音のWAVファイルを作ってzip圧縮すると「高圧縮ファイル爆弾です」みたいに誤検出したりしますので（avastとかそうだったかな？）
無音WAVってZIPにすると大幅に容量減りますから膨張率が高い危険ファイルと判定されるのでしょう。
何重に入れ子にしているかどうかとか関係なく、普通に膨張率が一定以上になれば検出するはずです。
Googleドライブは、zipファイルのウイルススキャンはダウンロード時で、膨張率が高かったりウイルスチェックに時間がかかるようなzipの場合、
ダウンロード時にメモリ容量とCPU使用量などのリソースで規制しているみたいで、
「ウイルススキャンが正常に終了しませんでした（タイムアウト） このファイルは危険な可能性があります」みたいな表示になります。
警告を無視してダウンロード（危険を承知でダウンロードみたいなリンク）をすることはできました。
逆にZIP爆弾は大丈夫だけど、ZIP爆弾を解凍した後のファイルを不正扱いするクラウドストレージもありました。
昔の音楽CDは後ろの方に長時間(10分とか)を無音で入れてそのあとに音楽入れる隠しトラックみたいなのがあったりするんですが、それをリッピングしたwavデータはYahooボックスに居れようとすると、DoS攻撃かなんかと誤解されてパケットドロップされました。
エラーメッセージも表示されず、こっちから送ったパケットをそのまま低レイヤーでドロップするようなBANをされます。
同じ容量の有音WAVファイルは大丈夫なので、同じビットが続くようなファイルをDoS攻撃と判定する仕組みになっていたのでしょう。
Yahoo! Boxの場合、こういった無音WAVファイルはzipにするとアップロード可能でした。
（今はYahoo!ボックスのPCからのアップロードは終了しています）
Re: (スコア:0)
アンチウィルスじゃなくて解凍ソフトやzlibが対策すべきじゃない？
解凍ソフトも対策済み (スコア:4, 参考になる)
unzip みたいな解凍ソフトも対策済みでした
例えば debian で試しにzbsm.zipを解凍してみると
$ unzip zbsm.zip
inflating: 0
error: invalid zip file with overlapped components (possible zip bomb)
という風に，zip bombを検出してエラーを出してくれました
zbsm.zipは全部展開すると5GBになるZIP爆弾ですが
unzipは21MBほど展開したところで上記のエラーを出して処理を中断してくれました．
Re: (スコア:0)
＞長時間無音のWAVファイルを作ってzip圧縮すると
正当な目的で作られて居る可能性も有る訳だから、注意喚起程度だろう。
その手の注意喚起自体はUI的に統一した方がユーザーも分かり易いと考えると、
アンチウイルスがその仕事しているってのも別に変でも無いだろう。
ZIP64形式を用いると46MBのファイルが4.5PBに膨らむ (スコア:3, おもしろおかしい)
Re: (スコア:0)
早くストレージや通信量がペタバイト級の時代にならないかな。
そしたら惜しげもなくペタペタ言えるからな
Re: (スコア:0)
曲率半径が大きいほど平坦になるのです..
Re: (スコア:0)
ふと思ったけど (スコア:0)
これ逆に考えたら
理論上は281TBを10MBに圧縮できるってこと？
Re: (スコア:0)
AAAAAA…で281TBなら、理論上は8bit+64bitの9byteに圧縮できるよ。
Re:ふと思ったけど (スコア:5, おもしろおかしい)
Re: (スコア:0)
素直にうまいと思った
Re: (スコア:0)
Aカップでトップとアンダーの差5cmで1カップ辺り2.5cm差なのでペタンは理論上AAAですよ
Re: (スコア:0)
8bit+49bitで8byteで可能じゃないですか。
281T 2^9 * (2^10)^4 = 2^49
どこか計算間違ってるかな。
もしかして、long integerで64bitかな。
8byteでも9byteでもどっちでもたいした違いはないけど。
Re: (スコア:0)
どうでもいいけど、それだとビット長の情報が足りてないのでは。
まぁ、バイト単位に制限すれば3ビットで足りるけど。
Re: (スコア:0)
これ逆に考えたら
理論上は281TBを10MBに圧縮できるってこと？
意味のあるデータである必要はないよね
掛け算、割り算、etc...
Re: (スコア:0)
それ言ったら無限を1バイトまで圧縮できますがな。
2.71828...→e
3.14159...→π
みたいな。
Re:ふと思ったけど (スコア:1)
πはUTF-8では2オクテット（U+03C0）
Re: (スコア:0)
パイの文字って1バイトで表現できたっけ?
Re: (スコア:0)
ISO 8859-7 ならね。
Re:ふと思ったけど (スコア:1)
あと、MZ-80系
-- う～ん、バッドノウハウ？
Re: (スコア:0)
学部の情報理論やっていれば、理論上はエントロピーまでいけるやん
エントロピー限りなく低い冗長なデータなら理論上はいくらでも小さくなる
ちなみにZIPのプログラムのバグや誤動作は関係ないよ
Re: (スコア:0)
そんなに大容量を圧縮できるならゲルまゆしぃにならずにすみそう
Re: (スコア:0)
あらゆるファイルを1バイトに圧縮できる究極の圧縮プログラムTHcompを用いれば……
https://thcomp.org/pen/pfyp/thcomp/thc00.html [thcomp.org]
Re: (スコア:0)
最初に圧縮する256個までで以降は2バイト、3バイト…じゃなかったっけ
Re:ふと思ったけど (スコア:1)
一番最初のthcomp自身は0バイトですね。ファイルサイズ自体も情報になってる。
理論上最長は11バイトだっけ。今時なら4～5バイトあたりにまで伸びてるかなぁ。
Re: (スコア:0)
要するに短縮URLじゃないか
Re:ふと思ったけど (スコア:1)
まぁ、もし今の時代にリアルに実装するなら、そういう事。
アップローダーにファイルをアップしたらダウンロード用のURLが返ってくる（末尾がID）、という形で今日では普通に実用されてます。
しかし、当時はまだWWWもなく、URLの概念がなかった時代。
ネットワークへの常時接続も高速通信も無い。
人々がデータの代わりに識別子をやり取りし、その識別子から当たり前のように元データを参照できるなんてことは無かった時代なのです。
元ネタの作者もアップローダー＋IDという事は考えておらず、人類の生み出す全データに対する完全ハッシュという数学的ネタだったのだそうです。
とは言え、現実のインターネットとURLは、巨大なデータベースとデータへのハッシュに見える点では興味深くありますね。
Re: (スコア:0)
知らないなら黙ってろ
Re:ふと思ったけど (スコア:1)
それをコルモゴロフ複雑性 [wikipedia.org]という
ははーん (スコア:0)
解凍したら無題.bmpが入っているわけですね。
わかめ (スコア:0)
とどちらが増えるの？
Re:わかめ (スコア:1)
わかめは増えない
大きくなるだけだ
Re:わかめ (スコア:1)
なんだと？
理研に騙されていたのか！
Re: (スコア:0)
増えるわかめはありまぁす
Re: (スコア:0)
あれ、水含んで太るだけで、ワカメ自体の質量は変わらないんじゃ・・・
Re:わかめ (スコア:1)
細胞の隙間に入っただけなら「ワカメは増えない」と言えるが、細胞構造なかに水が使われると「ワカメは増えている」とも言える。
それがワカメかどうかってのは又別の話だが。
しかし寒天に水は水を含んでの寒天だよね。
＃なんか木材の「正しい」水分ってだけで一日会議が紛糾したのを思い出した。
Re: (スコア:0)
Re: (スコア:0)
閉鎖時空に生きるワカメちゃんは膨らまない。
でも、同じ閉鎖時空でも、シズカちゃんは膨らんでいると聞く。すこしふしぎ。
自宅のストレージなら (スコア:0)
今は300TBまで耐えられるので281TBならギリ耐えられる
尚、ノリで組んだだけで使ってる容量は音楽ファイルやOSのバックアップなので
1TBほどの模様
Re:自宅のストレージなら (スコア:2)
贅沢な趣味ですねえ。いくらかかりました？
Re:自宅のストレージなら (スコア:1)
カード合わせても400万でかかってるかどうかですね
流石にHDD自体はSATAなのでSASHDDと悩んだけど容量でかい方が面白かろうと。
HDDをロット分散させるのにばらけて買ってるので分からん
自宅のデカブツ友人に見られるたびにお前はバカか？と言われるけど
嫌なことあっても俺は家に帰ったら300TBのストレージ持ってるんだぞ！と思うと元気になります
Re:自宅のストレージなら (スコア:1)
300TBでいけると思ってたら272TiBしかなくてギリ耐えられないというオチを期待してます
Re: (スコア:0)
まだポートは余ってるんじゃよ
なるほど (スコア:0)
SERNのLHCを使わなくても超圧縮できるじゃん
Re: (スコア:0)
おまえヘリウムを圧縮すれば水爆になると勘違いしてないだろうな？
Re: (スコア:0)
STEINS;GATE ネタだよ。綴り違うじゃん。
Re: (スコア:0)
なかみスカスカのゲルバナデータですしね
ハードリンク (スコア:0)
Gigazineの記事を読む限りハードリンク的なことをして容量を膨らましてるっぽい。
FATでもハードリンクできるらしいし、参照先を同じにすればできるわな。
同じファイルが含まれる場合ってちょくちょくあるだろうけど、普通に圧縮するときにそういう使い方することあるのかな。
あるとすれば対策は難しそうだ。
ついでにあるエントリの何バイト目から何バイト目みたいな指定ができれば便利…どころじゃないな。ソリッド圧縮ができることになる。
まぁ圧縮済みファイルを途中から読みだすのは大変だから工夫が多少は必要だけど。
Re:プログラマー (スコア:1)