As a former boss used to say: "Unlimited is a bad idea."

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.

Circa 1997 a coworker lamented that he had signed up for some email list, and attempts to unsubscribe weren’t working (more of a manual thing, IIRC). I made the suggestion to set up a cronjob to run hourly, to send an email request to be unsubscribed. It would source a text file containing the request to be unsubscribed. And with each iteration, it would duplicate the text from the file, effectively a geometric progression. The list owner responded about a week or so later, rather urgently requesting that my coworker cut it out, saying that he would remove him from the list. Apparently the list owner had been away on vacation the entire time.

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.

I always liked the RP DNS record (https://www.rfc-editor.org/rfc/rfc1183) but no one seems to know about it or use it any more. The only reason my servers don't have one now is because route53 doesn't support it.

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

That's why everyone else is lazy and just ping google.com

What was it about NT that made an admin unnecessary? Just marketing?

I never found this out, but there was some feature where NT would try to negotiate an encrypted connection to communicate and that’s the port it was connecting on. It’s a long time ago. It’s possible the box had been pwned, and that was command/control for a botnet or something. Lots of internet-facing windows boxes were at the time because MS security was absolutely horrendous at this time.

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.

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.

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

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

ln -s /dev/urandom /dev/zipbomb && echo 'Boom!'

Ok, not a real zip bomb, for that we would need a kernel module.

You yourself explain how it could've worked: Plenty of webservers are or were not chroot'ed.

I guess it depends on the server's implementation. but, since you need some logic to decide when to serve the html bomb anyway, I don't see why you would prefer this solution. Just use whatever script you're using to detect the bots to serve the bomb.

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

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

Bad bot

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

But the bot likely only automatically unpacks the outer layer. So nesting doesn't help with bot deterrence.

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

Last time I checked, the tab keeps loading, freezes, and the process that's assigned to rendering the tab gets killed when it eats too much RAM. Might cause a "this tab is slowing down your browser" popup or general browser slowness, but nothing too catastrophic.

How bad the tab process dying is, depends per browser. If your browser does site isolation well, it'll only crash that one website and you'll barely notice. If that process is shared between other tabs, you might lose state there. Chrome should be fine, Firefox might not be depending on your settings and how many tabs you have open, with Safari it kind of depends on how the tabs were opened and how the browser is configured. Safari doesn't support zstd though, so brotli bombs are the best you can do with that.

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.

I once worked for a US state government agency and my coworker was the main admin of our WordPress based portal and it was crazy how much work it was to keep working.

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

Hey, I check /wp-admin sometimes when I see a website and it has a certain feel to it

I do the same. Great way to filter our security scanners.

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.

apart from blind users, who are also now completely unable to use their screenreaders with your site

“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?

Weird that text browsers just ignore all the attributes that hide elements. I get that they don't care about styling, but even a plain hidden attribute or aria-hidden are ignored.

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.

Same, using ipsets, and a systemd {service,timer} for updating the lists.

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?

Kinda wonder if a "content labyrinth" could be used to influence the ideas / attitudes of bots -- fill it with content pro/anti Communism, or Capitalism, or whatever your thing is, hope it tips the resulting LLM towards your ideas.

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.

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.

The whole point is for it to cost less (ie, smaller size) for the sender and cost more (ie, larger size) for the receiver.

The compression ratio is the whole point... if you can send something small for next to no $$ which causes the receiver to crash due to RAM, storage, compute, etc constraints, you win.

No, it's not about sending large files over the wire, it's about saturating the RAM of the script that reads the content. If the script is naive enough, a zip bomb will do. Example on my machine, such a snippet will cause the OS to close the python process:

    >>> from requests import get
    >>> r = get("https://acme.tld/trap/")
    >>> r.text

The server doesn't do much (serving a relatively small number of bytes) while the client basically crashes.

> 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?

Ha ha, that compressor is some evil genius.

Brings to mind this 30+ year old IOCCC entry for compressing C code by storing the code in the file names.

https://www.ioccc.org/1993/lmfjyh/index.html

undefined

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.

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.

> 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?

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.

Just put a "by connecting to this service, you agree to and authorize…" at the front of the zipbomb.

(I'm half-joking, half-crying. It's how everything else works, basically. Why would it not work here? You could even go as far as explicitly calling it a "zipbomb test delivery service". It's not your fault those bots have no understanding what they're connecting to…)

So the trick is to disguise it as an accident. Have the zip bomb look like a real HTML file at the beginning, then have zeroes after that, like it got corrupted.

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.

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.

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

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.

Yes.

A user has to manually unpack a zip bomb, though. They have to open the file and see "uncompressed size: 999999999999999999999999999" and still try to uncompress it, at which point it's their fault when it fills up their drive and fails. So I don't think there's any ethical dilemma there.

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.

Compressing a sequence of any single character should give almost identical results length-wise (perhaps not exactly identical, but the difference will be vanishingly small).

For example, with gzip using default options:

    me@here:~$ pv /dev/zero -s 10M -S | gzip -c | wc -c                    
    10.0MiB 0:00:00 [ 122MiB/s] [=============================>] 100%      
    10208                                                                  
    me@here:~$ pv /dev/zero -s 100M -S | gzip -c | wc -c                   
     100MiB 0:00:00 [ 134MiB/s] [=============================>] 100%      
    101791                                                                 
    me@here:~$ pv /dev/zero -s 1G -S | gzip -c | wc -c                     
    1.00GiB 0:00:07 [ 135MiB/s] [=============================>] 100%      
    1042069                                                                
    me@here:~$ pv /dev/zero -s 10M -S | tr "\000" "\141" | gzip -c | wc -c 
    10.0MiB 0:00:00 [ 109MiB/s] [=============================>] 100%      
    10209                                                                  
    me@here:~$ pv /dev/zero -s 100M -S | tr "\000" "\141" | gzip -c | wc -c
     100MiB 0:00:00 [ 118MiB/s] [=============================>] 100%      
    101792                                                                 
    me@here:~$ pv /dev/zero -s 1G -S | tr "\000" "\141" | gzip -c | wc -c  
    1.00GiB 0:00:07 [ 129MiB/s] [=============================>] 100%      
    1042071

Two bytes difference for a 1GiB sequence of “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa…” (\141) compared to a sequence of \000.

The worst ones treat it as a target.

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

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.

undefined

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

Thanks for sharing!

The code shows both the 'middleware' and the custom list can put you in the naughty box

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

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.

> "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.

undefined

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

The logic of terrorists and war criminals everywhere.

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.