Fun with gzip bombs and email clients

Gzip/Zip bombs have been a thing for decades. Lets create a 10MB gzip file which decompresses to 10GB:

dd if=/dev/zero bs=1G count=10 | gzip > 10gb.gz

This is called a Gzip bomb, because when it is decompressed, it blows up to a much larger size (~1000 larger). Add it your website document root and configure Nginx to serve it up as an image, with gzip Content-Encoding:

location /10gb.png {
    default_type image/png;
    add_header   Content-Encoding gzip;
    try_files    /10gb.gz =404;
}

An HTTP client which fetches this file will see that the Content-Encoding is set to gzip and so will usually try to decompress it on the fly, meaning you will have sent 10MB of data over the network, but the HTTP client will now have 10GB of data to deal with.

Firefox doesn’t seem to have an issue with this. It figures out pretty quickly that it’s not an image and doesn’t seem to store the decompressed data anywhere.

What about email clients though? And what about the proxies that some email services have started to use to hide your IP from the sender? Send a html email containing:

src="https://YOUR_WEBSITE/10gb.png">

Thunderbird and Gmail’s web proxies, start to fetch the image, but bail out early before finishing fetching the 10MB. I’m not sure if this is because they can tell it’s not an image, or because they’re decompressing it, and hit a limit. Hopefully the latter. Either way, it works well.

Protonmail and iCloud webmail’s proxies seem to fetch the whole 10MB file, but discard it. Protonmail will warn you that it failed to load the image, and give you the option of loading it directly from your web browser (not using their proxy). If you say yes, you leak your IP, but the browser doesn’t crash. This works well.

Fastmail webmail’s proxies downloaded the full 10MB and proceeded to send me 385MB of data before giving up. The UI remained responsive, so although they should have bailed earlier, at least it works. I wonder if there is a 10GB file sat on one of their servers now.

iOS Mail partially downloads the file and then crashes. Not a great experience, but not the end of the World; you can just delete the email when you get back in.

Evolution Mail has no defense for this. It downloads the whole 10MB and then proceeds to fully decompress it into its cache/evolution/http/ directory. I sent myself an email with this in the body:

src="https://YOUR_HOSTNAME/10gb.png">
src="https://YOUR_HOSTNAME/10gb.png?x=1">
src="https://YOUR_HOSTNAME/10gb.png?x=2">
src="https://YOUR_HOSTNAME/10gb.png?x=3">
src="https://YOUR_HOSTNAME/10gb.png?x=4">
src="https://YOUR_HOSTNAME/10gb.png?x=5">
src="https://YOUR_HOSTNAME/10gb.png?x=6">
src="https://YOUR_HOSTNAME/10gb.png?x=7">
src="https://YOUR_HOSTNAME/10gb.png?x=8">
src="https://YOUR_HOSTNAME/10gb.png?x=9">

In less than a minute after clicking “Load remote content”, Evolution Mail had added 100GB of data to my laptops disk.

It’s always a good idea to code defensively when you’re fetching data from external services. Always assume some smart arse will make their server send you more data than is reasonable.

Another weird thing I noticed about Evolution Mail when testing this. It caches the downloaded remote content in a file with a filename consisting of an MD5 of the URL. But if you don’t use one of the limited query string formats they like, they remove the query string from the MD5 calculation. According to Evolution Mail’s cache these two URLs are the same and should be cached to the same file:

So if you receive an email containing an https://www.example.com/foo?image1">, and then receive a second email containing an https://www.example.com/foo?image2"> the cached image from the first email is displayed in the second email.