# 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:

```text
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](https://nginx.org/) to serve it up as an image, with gzip
Content-Encoding:

```nginx
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](https://getfirefox.com) 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:

```html
<img src="https://YOUR_WEBSITE/10gb.png">
```

[Thunderbird](https://getthunderbird.com) 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](https://proton.me/mail) 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](https://www.fastmail.com/) 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](https://wiki.gnome.org/Apps/Evolution) 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:

```html
<img src="https://YOUR_HOSTNAME/10gb.png">
<img src="https://YOUR_HOSTNAME/10gb.png?x=1">
<img src="https://YOUR_HOSTNAME/10gb.png?x=2">
<img src="https://YOUR_HOSTNAME/10gb.png?x=3">
<img src="https://YOUR_HOSTNAME/10gb.png?x=4">
<img src="https://YOUR_HOSTNAME/10gb.png?x=5">
<img src="https://YOUR_HOSTNAME/10gb.png?x=6">
<img src="https://YOUR_HOSTNAME/10gb.png?x=7">
<img src="https://YOUR_HOSTNAME/10gb.png?x=8">
<img 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:

- https://www.example.com/foo?image1
- https://www.example.com/foo?image2

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

<strong>[edit]</strong> Somebody has helpfully [reported the above
issues](https://gitlab.gnome.org/GNOME/evolution/-/issues/3101) to the Evolution
Mail project. I don't engage with that project directly anymore due to previous
poor treatment by it's members.