Zlib DEFLATE減圧爆弾
ZlibのDEFLATEメソッドを使用して解凍すると、はるかに長いものに展開される短いデータ文字列の例を教えてください。
より正確には、ZlibのDEFLATE用に構築できる最も厄介な減圧爆弾は何ですか？ここでの性能指数は圧縮率です。圧縮されたファイルがnバイトの長さであり、解凍後に何かmバイト長の場合、圧縮率はm/nです。私は、圧縮率を最大化するものを探しています。うまくいけば、圧縮データが非常に短くなります。誰か私にそのような減圧爆弾の例を教えてもらえますか？
関連： この投稿 DEFLATEは1032の圧縮率に漸近的に近づくことができると主張しています。それは最善の方法ですか、それとも、慎重に選択された一連の圧縮バイトを選択した場合に、より高い圧縮率を達成できるのでしょうか。 Libpng defends リソース制限を課すことによって減圧爆弾に反対しますが、それらは特定の減圧爆弾の具体例を示していません。 Zip bombs も参照してください。これは対応する攻撃ですが、Zipファイル形式です。
「1032：1」の図の出典は zlibサイト に記載されています。
制限は、1つの長さ/距離のペアが最大258の出力バイトを表すことができるという事実から来ています。長さには少なくとも1ビット、距離には少なくとも1ビットが必要なので、2ビット入力では258バイト、8ビット入力では1032バイトを出力できます。ダイナミックブロックには長さの制限がないため、1032：1の制限に任意に近づけることができます。
これは、zlibの2人の設計者の1人であるMark Adlerからの引用です。私自身がDeflateのライブラリーを実装したので、 アルゴリズム がどのように機能するかを考えると、この漸近的な制限は確かに真です（あなたはそれ以上行くことはできませんが、望みどおりに近づくことができます）。 Deflateは「コピー」をエンコードすることで機能します。各要素は新しいバイトまたは過去のシーケンスのコピーです。コピーは重複する可能性があります（つまり、距離4で長さ30のシーケンスをコピーして、過去の4バイトのシーケンスの15倍を生成できます）。要素のシーケンスにハフマンコードが適用されます。最小限の長さの「コピー」を取得するには、多くの部分をオーバーラップする必要があり、各コピーには最大で258バイトの価値があります。したがって、圧縮されるデータは、同じバイトの長い文字列でなければなりません。
@Steffenが言うように、gzipでゼロの長いシーケンスを圧縮すると、1000：1を超える圧縮率が得られます。ゼロである必要はありません。同じバイト値で構成されるシーケンスが何度も繰り返されます。 Linuxマシンには/dev/zeroではなく/dev/fortytwoがあります。
「圧縮爆弾」はかなり昔にすでに活動していた。私はそれが1996年にNetscapeを殺すために採用されているのを見ました（当時、Netscapeは背景画像を処理しましたが、Mosaicは処理しませんでした。非常に小さなGIFファイルが巨大な背景をエンコードでき、NetscapeはX11サーバーで単一の大きなピックスマップとして割り当てました）。
zlib deflateはgzipで使用されます。あなたが使うかもしれない10M入力からab 10k爆弾を作成するには
dd if=/dev/zero bs=1024 count=$((10*1024)) | gzip -9 > bomb.gz
そして、私はあなたが約1000の最大比率を持っていると主張するのに正しい投稿だと思います。詳細は http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html にあります=（古い）しかし http://blog.cyberis.co.uk/2013_08_01_archive.html は、ほとんどの最新のブラウザーがまだ保護されていないことを示しています。