That doesn't necessarily need to be in the request itself.

You can also limit the wider process or system your request is part of.

Back then things like postmaster@theirdomain and webmaster@theirdomain were read by actual people. Also the whois command often worked.

You can also find out who owns a general group of IP addresses, and at the time they would often assist you in further pinpointing who is responsible for a particular address.

tech-c / abuse addresses were commonly available on whois.

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 had a ton of trouble opening a 10MB or so png a few weeks back. It was stitched together screenshots forming a map of some areas in a game, so it was quite large. Some stuff refused to open it at all as if the file was invalid, some would hang for minutes, some opened blurry. My first semi-success was Fossify Gallery on my phone from F-Droid. If I let it chug a bit, it'd show a blurry image, a while longer it'd focus. Then I'd try to zoom or pan and it'd blur for ages again. I guess it was aggressively lazy-loading. What worked in the end was GIMP. I had the thought that the image was probably made in an editor, so surely an editor could open it. The catch is that it took like 8GB of RAM, but then I could see clearly, zoom, and pan all I wanted. It made me wonder why there's not an image viewer that's just the viewer part of GIMP or something.

Among things that didn't work were qutebrowser, icecat, nsxiv, feh, imv, mpv. I did worry at first the file was corrupt, I was redownloading it, comparing hashes with a friend, etc. Makes for an interesting benchmark, I guess.

For others curious, here's the file: https://0x0.st/82Ap.png

I'd say just curl/wget it, don't expect it to load in a browser.

I once encoded an entire TV OP into a multi-megabyte animated cursor (.ani) file.

Surprisingly, Windows 95 didn't die trying to load it, but quite a lot of operations in the system took noticeably longer than they normally did.

Nah, back then we paid for bandwidth by the kb.

Looks like something I should add for my web APIs which are to be queried only by clients aware of the API specification.

Bad bot

I remember reading about that some years ago. It involved Windows NT.

https://www.google.com/search?q=windows+nt+bug+affects+ship

Can you hand edit to create recursive file structures to make it infinite? I used to use debug in dos to make what appeared to be gigantic floppy discs by editing the fat

Wouldnt that defeat the attack though as you arent serving the large content anymore

Hosting WordPress myself for 13 years now and have no problem :) Just follow standard security practices and don't install gazillion plugins.

Never use that junk if you value your sanity, I think you mean.

Ditto to self-hosting wordpress works fine with standard hosting practices and not installing a bazillion random plugins.

I did essentially the same thing. I have this input in a form:

    <label for="gb-email" class="nah" aria-hidden="true">Email:</label>
    <input id="gb-email"
           name="email"
           size="40"
           class="nah"
           tabindex="-1"
           aria-hidden="true"
           autocomplete="off"
    >

With this CSS:

    .nah {
      opacity: 0;
      position: absolute;
      top: 0;
      left: 0;
      height: 0;
      width: 0;
      z-index: -1;
    }

And any form submission with a value set for the email is blocked. It stopped 100% of the spam I was getting.

We use to just call those honeypot fields. Works like a charm.

Oh that is great.

“aria-hidden” would spare those users, and possibly be ignored by the bots unless they are sophisticated.

Manual banning is about the same since you just book /56 or bigger, entire providers or countries.

Automated banning is harder, you'd probably want a heuristic system and look up info on IPs.

IPv4 with NAT means you can "overban" too.

I think they are suggesting the range of IPs to block is too high?

Maybe it’s easier to circumvent because getting a new IPv6 address is easier than with IPv4?

true, but you can make the link text 'do not click this' or 'not a real link' to let them know. I'm not sure if crawlers have started using LLMs to check pages or not which would be a problem.

Undoubtedly. If you go poking around most any security product (the product I was referring to was not in the EDR space,) you'll see these sorts of issues all over the place.

is that endpoint detection and response?

This doesn't work if you pay bandwidth and CPU usage for your servers though.

Wouldn't this just waste your own bandwidth/resources?

I currently cannot tell without making a little configuration change, because as soon as an IP address is logged as having visited the trap URL (honeypot, or zipbomb or whatever), a log monitoring script bans that client.

Secondly, I know that most of these bots do not come back. The attacks do not reuse addresses against the same server in order to evade almost any conceivable filter rule that is predicated on a prior visit.

Doesn't deal with multi-file ZIP archives. And before you think you can just reject user uploads with multi-file ZIP archives, remember that macOS ZIP files contain the __MACOSX folder with ._ files.

https://github.com/uint128-t/ZIPBOMB

  2048 yottabyte Zip Bomb

  This zip bomb uses overlapping files and recursion to achieve 7 layers with 256 files each, with the last being a 32GB file.

  It is only 266 KB on disk.

When you realise it's a zip bomb it's already too late. Looking at the file size doesn't betray its contents. Maybe applying some heuristics with ClamAV? But even then it's not guaranteed. I think a small partition to isolate decompression is actually really smart. Wonder if we can achieve the same with overlays.

    import zipfile
    with zipfile.ZipFile("zipbomb.zip") as zip:
        for name in zip.namelist():
            print("working on " + name)
            left = 1000000
            with open("dest_" + name, "wb") as fdest, zip.open(name) as fsrc:
                while True:
                    block = fsrc.read(1000)
                    if len(block) == 0:
                        break
                    fdest.write(block)
                    left -= len(block)
                    if left <= 0:
                        print("too much data!")
                        break

Seems like a good and simple strategy to me. No real partition needed; tmpfs is cheap on Linux. Maybe OP is using tools that do not easily allow tracking the number of uncompressed bytes.

Yes I'd rather deal with a simple out of disk space error than perform some acrobatics to "safely" unzip a potential zip bomb.

Also zip bombs are not comically large until you unzip them.

Also you can just unpack any sort of compressed file format without giving any thought to whether you are handling it safely.

> He found out later (after a defrag) that the "compressor" was just hiding data in unused disk sectors and storing references to them

So you could access the files until you wrote more data to disk?

man, a comment that brings back memories. you and me both.

The reason why the discussion in this thread centers around gzip (and brotli / zstd) is because those are standard compression schemes that HTTP clients will generally support (RFCs 1952, 7932, and 8478).

As far as I can tell, the biggest amplification you can get out of zstd is 32768 times: per the standard, the maximum decompressed block size is 128KiB, and the smallest compressed block is a 3-byte header followed by a 1-byte block (e.g. run-length-encoded). Indeed, compressing a 1GiB file of zeroes yields 32.9KiB of output, which is quite close to that theoretical maximum.

Brotli promises to allow for blocks that decompress up to 16 MiB, so that actually can exceed the compression ratios that bzip2 gives you on that particular input. Compressing that same 1 GiB file with `brotli -9` gives an 809-byte output. If I instead opt for a 16 GiB file (dd if=/dev/zero of=/dev/stdout bs=4M count=4096 | brotli -9 -o zeroes.br), the corresponding output is 12929 bytes, for a compression ratio of about 1.3 million; theoretically this should be able to scale another 2x, but whether that actually plays out in practice is a different matter.

(The best compression for brotli should be available at -q 11, which is the default, but it's substantially slower to compress compared to `brotli -9`. I haven't worked out exactly what the theoretical compression ratio upper bound is for brotli, but it's somewhere between 1.3 and 2.8 million.)

Also note that zstd provides very good compression ratios for its speed, so in practice most use cases benefit from using zstd.

> There's literally no machine on Earth today that can deal with that (as a single file, I mean).

Oh? Certainly not in RAM, but 4 PiB is about 125x 36TiB drives (or 188x 24TiB drives). (You can go bigger if you want to shell out tens of thousands per 100TB SSD, at which point you "only" need 45 of those drives.)

These are numbers such that a purpose-built server with enough SAS expanders could easily fit that within a single rack, for less than $100k (based on the list price of an Exos X24 before even considering any bulk discounts).

That's far from the ultimate zip bomb.

42.zip has five layers. But you can make a zip file that has an infinite number of layers. See https://research.swtch.com/zip or https://alf.nu/ZipQuine

Do must unzip programs work recursively by default?

In general, this theoretical problem is called the Kolmogorov Complexity of a string: the size of the smallest program that outputs a the input string, for some definition of "program", e.g., an initial input tape for a given universal turing machine. Unfortunately, Kolmogorov Complexity in general is incomputable, because of the halting problem.

But a gzip decompressor is not turing-complete, and there are no gzip streams that will expand to infinitely large outputs, so it is theoretically possible to find the pseudo-Kolmogorov-Complexity of a string for a given decompressor program by the following algorithm:

Let file.bin be a file containing the input byte sequence.

1. BOUNDS=$(gzip --best -c file.bin | wc -c)

2. LENGTH=1

3. If LENGTH==BOUNDS, run `gzip --best -o test.bin.gz file.bin` and HALT.

4. Generate a file `test.bin.gz` LENGTH bytes long containing all zero bits.

5. Run `gunzip -k test.bin.gz`.

6. If `test.bin` equals `file.bin`, halt.

7. If `test.bin.gz` contains only 1 bits, increment LENGTH and GOTO 3.

8. Replace test.bin.gz with its lexicographic successor by interpreting it as a LENGTH-byte unsigned integer and incrementing it by 1.

9. GOTO 5.

test.bin.gz contains your minimal gzip encoding.

There are "stronger" compressors for popular compression libraries like zlib that outperform the "best" options available, but none of them are this exhaustive because you can surely see how the problem rapidly becomes intractable.

For the purposes of generating an efficient zip bomb, though, it doesn't really matter what the exact contents of the output file are. If your goal is simply to get the best compression ratio, you could enumerate all possible files with that algorithm (up to the bounds established by compressing all zeroes to reach your target decompressed size, which makes a good starting point) and then just check for a decompressed length that meets or exceeds the target size.

I think I'll do that. I'll leave it running for a couple days and see if I can generate a neat zip bomb that beats compressing a stream of zeroes. I'm expecting the answer is "no, the search space is far too large."

It’s a zip bomb, so does the creator care? I just mean from a practical standpoint - overflows and crashes would be a fine result.

I mean, if I make a new compression algorithm that says a 10GB file of zeros is represented with a single specific byte, that would technically be compression.

All depends on how much magic you want to shove into an "algorithm"

No lossless algorithm can compress all strings; some will end up larger. This is a consequence of the pigeonhole principle.

But of course there is. Imagine the following compression scheme:

    0-253: output the input byte
    254 followed by 0: output 254
    254 followed by 1: output 255
    255: output 10GB of zeroes

Of course this is an artificial example, but theoretically it's perfectly sound. In fact, I think you could get there with static huffman trees supported by some formats, including gzip.

I don't believe the client counts as a protected computer because they initiated the connection. Also a protected computer is a very specific definition that involves banking and/or commerce and/or the government.

There is IMO no legal use case for an external computer system to initiate a connection with my system without prior legal agreement. It all happens on good will and therefore can be terminated at any time.

There is IMO no legal use case for an external computer system to initiate a connection with my system without prior legal agreement. It all happens on good will.

Though ethically it might be a good thing to shut down their infected computer, instead of keeping it running.

Well creating a bot is not per se illegal, so assuming the maliciousness-detector on the server isn’t perfect, it could serve the zip bomb to a legitimate bot. And I don’t think it’s crazy that serving zip bombs with the stated intent to sabotage the client would be illegal. But I’m not a lawyer, of course.

Anyone can sue anyone for anything and the side with the most money is most likely to prevail.

Mantrapping is a fairly good analogy, and that's very illegal. If the person reading your gas meter gets caught in your mantrap, you're going to prison. You're probably going to prison if somebody burglarizing you gets caught in your mantrap.

https://en.wikipedia.org/wiki/Mantrap_(snare)

Of course their computers will live, but if you accidentally take down your own ISP or maybe some third-party service that you use for something, I'd think they would sue you.

I’m not sure that’s enough, robots.txt isn’t really legally binding so if the zip bomb somehow would be illegal, guarding it behind a robots.txt rule probably wouldn’t make it fine.

I meant that all of the byte values would be the same (so they would still be repeating), but a different value than zero. However, Brotli could be another idea if the client supports it.

Also might open up a new DoS vector on entropy consumed by /dev/random so it can be worse than 1:1.

That's clear. It all comes down to their behavior. Will they sit there waiting to finish this download, or just start sending other requests in parallel until you dos yourself? My hope is they would flag the site as low-value and go looking elsewhere, on another site.

The idea is to trickle it very slowly, like keeping a cat occupied with a ball of fluff in the corner.

Many people would be better off sticking with the former than realizing what Paris actually is and being disappointed.

https://en.wikipedia.org/wiki/Paris_syndrome

I think that's the point, you'd use robots.txt to direct Googlebot/Bingbot/etc away from countermeasures that could potentially mess up your SEO. If other bots ignore the signpost clearly saying not to enter the tarpit, that's their own stupid fault.

The ones that survive do

Based on the example in the post, that thinking might need to be extended to "someone happening to be using a blocklisted IP." I don't serve up zip bombs, but I've blocklisted many abusive bots using VPN IPs over the years which have then impeded legitimate users of the same VPNs.

This is William Gibson's "black ICE" becoming real, and I love it.

https://williamgibson.fandom.com/wiki/ICE

At least, not with the default rules. I read that discussion a few days ago and was surprised how few callouts there were that a WAF is just a part of the infrastructure - it is the rules that people are actually complaining about. I think the problem is that so many apps run on AWS and their default WAF rules have some silly content filtering. And their "security baseline" says that you have to use a WAF and include their default rules, so security teams lock down on those rules without any real thought put into whether or not they make sense for any given scenario.

I did actually try zip bombs at first. They didn't work due to the architecture of how Amazon's scraper works. It just made the requests get retried.

> "Hurting people is wrong, so you should not defend yourself when attacked."

This is exactly what Californian educators told kids who were being bullied in the 90's.

> a smaller wrong is the best recourse we have to avert a greater wrong

The logic of terrorists and war criminals everywhere.