Comment by M95D

7 months ago

I wonder if I could create a 500TB html file with proper headers on a squashfs, an endless <div><div><div>... with no closing tags, and if I could instruct the server to not report file size before download.

Any ideeas?

Why use squashfs when you can do the same OP did and serve a compressed version, so that the client is overwhelmed by both the uncompression and the DOM depth:

yes "<div>"|dd bs=1M count=10240 iflag=fullblock|gzip | pv > zipdiv.gz

Resulting file is about 15 mib long and uncompresses into a 10 gib monstrosity containing 1789569706 unclosed nested divs

Yes, servers can respond without specifying the size by using chunked encoding. And you can do the rest with a custom web server that just handles request by returning "<div>" in a loop. I have no idea if browsers are vulnerable to such a thing.

  • I just tested it via a small python script sending divs at a rate of ~900mb (as measured by curl) and firefox just kills the request after 1-2 gb received (~2 seconds) with an "out of memory" error, while chrome seems to only receive around 1mb/s, uses 1 cpu core 100%, and grows infinitely in memory use. I killed it after 3 mins and consuming ca. 6GB (additionally, on top of the memory it used at startup)

  • I would make it an invisible link from the main page (hidden behind a logo or something). Users won't click it, but bots will.

    • the problem with this is that for a tarpit, you just don't want to make it expensive for bots, you also want to make it cheap for yourself. this isn't cheap for you. a zip bomb is.

      2 replies →