https://www.grepular.com/Fun_with_Gzip_Bombs_and_Email_Clients

Grepular

Log inHomeProjectsBlog

Fun with Gzip Bombs and Email Clients

Written 5 hours ago by Mike Cardwell

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:

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

<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 <img src="https://
www.example.com/foo?image1">, and then receive a second email
containing an <img src="https://www.example.com/foo?image2"> the
cached image from the first email is displayed in the second email.

Want to leave a tip?BitcoinMoneroZcashPaypalYou can follow this Blog
using RSS or Mastodon. To read more, visit my blog index.

Website design, production and hosting by Mike Cardwell

Digital OceanBitcoinMoneroZcashPaypalRSS Feed