A Zip Bomb is a small Zip file that exploits capabilities of compression algorithms and settings to expand into a file or set of files that consume system resources to the point of system unusability. Didier Stevens, continuing his recent work in finding interesting sections of the PDF data scheme, has described techniques for the PDF equivalent of the Zip bomb, or a PDF Bomb.
Stevens' discovery comes after he looked closer at PDF Stream Objects. Within the PDF specification, a stream object is merely a form of packaging data as a sequence of bytes using one of a variety of encoding methods. A compliant PDF reader will then interpret the PDF file and reconstitute the stream object as the data that it originally represented. The great power of a stream object is that it allows the storage of complex visual representations in a straight forward and consistent manner.
It is the encoding options which is where the PDF Bomb gets its power from. Through the use of a 'stream filter' different encoding methods can be used to obfuscate the original data and provide a more compact means of storage when the filter being used is a compression filter. Stevens discovered that chaining two or more filters together, which he has dubbed a 'Filter Cascade' can lead to interesting outcomes when the resulting stream object is decoded by a compliant reader. Apart from the obvious system resource usage required to run subsequent filters on the same data, some of the filter options can be fed parameters that change how the data is filtered and how it is finally represented.
In testing, Stevens managed to create a PDF file that was only 2642 bytes in size, but which managed to decompress to 1GB of data through the use of filter parameters and filter cascading.
This now poses a challenge for antivirus/antimalware scanning software to adequately filter a booby-trapped PDF document without having to devote excessive resources to it. When other techniques for hiding malware in PDF files are considered (such as those already made public), it poses a seemingly impossible to solve problem for protective software developers. Because of the nature of PDF stream objects, techniques to identify and isolate Zip Bombs may not be applicable to PDF Bombs, though some observation of resource demands when filtering stream objects will highlight a potential PDF Bomb.
It is also a problem for PDF readers. How are they going to handle files that are created like this without failing? In Stevens' testing, he found that the 2642 byte PDF file was capable of bringing some readers to a halt. Perhaps some inbuilt monitoring of resource demands, similar to what is suggested above, will be a viable option for PDF reader developers.