Another fun one is the .zip or .tar.gz file that decompresses to itself: https://research.swtch.com/zip

If you are processing emails for security reasons, and want to find viruses even if they are in archive files, it's easy to write the code to "just keep unarchiving until we're out of things to unarchive", but not only can that lead to quite astonishing expansions, it can actually be a process that never terminates at all.

I remember when I first read about these, and "a small file that decompresses to a gigabyte" was also "a small file that decompresses to several multiples of your entire hard disk space" and even servers couldn't handle it. Now I read articles like this one talking about "oh yeah Evolution filled up 100GB of space" like that's no big deal.

If you have a recursive decompressor you can still make small files that uncompress to large amounts even by 2025 standards, because the symbols the compressor will use to represent "as many zeros as I can have" will themselves be redundant. The rule that you can't compress already-compressed content doesn't necessarily apply to these sorts of files.

I ran into one of these in the very early 00s; was working at a university (back in the days when a couple of people would run all the central servers, running Linux on beige PCs.) We had some anti-spam/AV software that looked at every incoming email hooked into Postfix, and the server kept running out of disk space.

Eventually tracked it down to an email which contained a zip of stock trading data – just the three letter stock code and the shift. It wasn't malicious, it just had an extraordinarily high compression ratio!

That Evolution mail caching behaviour is really sketchy. I wonder if it could be used for an exploit in the right scenario. If nothing else, it’s a good way to make an email that looks completely different depending on which client it’s opened in.

So can you construct valid image that would also act as zip bomb?

Jpeg and other lossy compression images should allow some of that, but dependens on compatibility of compression between gzip and image format.

There is that example where you have "zero image" of big dimensions, but can you actually conflate gzip and image compression?

Hmm that reminds me, it idly crossed my mind recently about whether AIs with online RAG have decent zip-bomb protection. This thought was provoked when I realised Perplexity would find and download and (apparently) analyse spreadsheet content. I'm sure there are zip-bomb equivalents in binary formats like .xlsx, PDF, .docx, etc.

Isn't that trivial to prevent zip bombs?

How does it work with Claws Mail/Sylpheed?

Yet another reason to prevent emails from downloading stuff from remote servers...

It appears that you can't do these sorts of things with with CID embedded images...