Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I use zip bombs to protect my server

idiallo.com

Post reply on HN
Print view View original

401–410 of 467 posts

Re: I use zip bombs to protect my server

#401

Post by wing-_-nuts »

immibis wrote: post #294
os2warpman wrote: post #106

Earlier quoted context omitted.

Anyone can sue anyone else for any reason. This is what trips me up: >On my server, I've added a middleware that checks if the current request is malicious or not. There's a lot of trust placed in: >if (ipIsBlackListed() || isMalicious()) { Can someone assigned a previously blacklisted IP or someone who uses a tool to archive the website that mimics a bot be served malware? Is the middleware good enough or "good enou…

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.

For some reason I was under the impression that browsers had the ability to transparently decompress certain archive formats? I may be thinking of less and gzip though

Re: I use zip bombs to protect my server

#402

Post by Dwedit »

fracus wrote: post #114

I'm curious why a 10GB file of all zeroes would compress only to 10MB. I mean theoretically you could compress it to one byte. I suppose the compression happens on a stream of data instead of analyzing the whole, but I'd assume it would still do better than 10MB.

There's around a 64KB block size limit for a block of compressed data. That sets a max compression ratio.

Re: I use zip bombs to protect my server

#403

Post by echoangle »

seqizz wrote: post #389
echoangle wrote: post #373

Earlier quoted context omitted.

No, why would they? If I voluntarily request your website, you can’t just reply with a virus that wipes my harddrive. Even though I had the option to not send the request. I didn’t know that you were going to sabotage me before I made the request.

Because you requested it? There is no agreement on what or how to serve things, other than standards (your browser expects a valid document on the other side etc). I just assumed court might say there is a difference between you requesting all guess-able endpoints and find 1 endpoint which will harm your computer (while there was _zero_ reason for you to access that page) and someone putting zipbomb into index.html t…

So serving a document exploiting a browser zero day for RCE under a URL that’s discoverable by crawling (because another page links to it) with the intent to harm the client (by deleting local files for example) would be legitimate because the client made a request? That’s ridiculous.

Re: I use zip bombs to protect my server

#404

Post by b2ccb2 »

JodieBenitez wrote: post #300

The same, for Caddy: https://www.dustri.org/b/serving-a-gzip-bomb-with-caddy.html 10T is probably overkill though.

Hilarious because the author, and the OP author, are literally zipping `/dev/null`. While they realize that it "doesn't take disk space nor ram", I feel like the coin didn't drop for them.

Think about it:

  $ dd if=/dev/zero bs=1 count=10M | gzip -9 > 10M.gzip
  $ ls -sh 10M.gzip 
  12K 10M.gzip
Other than that, why serve gzip anyway? I would not set the Content-Length Header and throttle the connection and set the MIME type to something random, hell just octet-stream, and redirect to '/dev/random'.

I don't get the 'zip bomb' concept, all you are doing is compressing zeros. Why not compress '/dev/random'? You'll get a much larger file, and if the bot receives it, it'll have a lot more CPU cycles to churn.

Even the OP article states that after creating the '10GB.gzip' that 'The resulting file is 10MB in this case.'.

Is it because it sounds big?

Here is how you don't waste time with 'zip bombs':

  $ time dd if=/dev/zero bs=1 count=10M | gzip -9 > 10M.gzip
  10485760+0 records in
  10485760+0 records out
  10485760 bytes (10 MB, 10 MiB) copied, 9.46271 s, 1.1 MB/s

  real    0m9.467s
  user    0m2.417s
  sys     0m14.887s
  $ ls -sh 10M.gzip 
  12K 10M.gzip

  $ time dd if=/dev/random bs=1 count=10M | gzip -9 > 10M.gzip
  10485760+0 records in
  10485760+0 records out
  10485760 bytes (10 MB, 10 MiB) copied, 12.5784 s, 834 kB/s

  real    0m12.584s
  user    0m3.190s
  sys     0m18.021s

  $ ls -sh 10M.gzip 
  11M 10M.gzip

Re: I use zip bombs to protect my server

#405

Post by sroussey »

Ugohcet wrote: post #325
M95D wrote: post #283

Earlier quoted context omitted.

I wonder if I could create a 500TB html file with proper headers on a squashfs, an endless ... 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 " "|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

You can also just use code to endlessly serve up something.

Also you can reverse many DoD vectors depending on how you are setup and costs. For example reverse Slowloris attack and use up their connections.

Re: I use zip bombs to protect my server

#406

Post by sureIy »

hombre_fatal wrote: post #356
carlosjobim wrote: post #78

Earlier quoted context omitted.

There's a lot of essential functionality missing from WordPress, meaning you have to install plugins. Depending on what you need to do. But it's such a bad platform that there really isn't any reason for anybody to use WordPress for anything. No matter your use case, there will be a better alternative to WordPress.

You can use WordPress as a static site generator: https://simplystatic.com/ Then WordPress is just your private CMS/UI for making changes, and it generates static files that are uploaded to a webhost like CloudFlare Pages, GitHub Pages, etc.

It has been a long time since I tried that, but it was never as simple as they claimed it to be.

Now that plugin became a service, at which point you might just use a WP host and let them do their thing.

Re: I use zip bombs to protect my server

#407

Post by swiftcoder »

opan wrote: post #166
bobmcnamara wrote: post #158

Earlier quoted context omitted.

I made a 64kx64k JPEG once by feeding the encoder the same line of macro blocks until it produce the entire image. Years later I was finally able to open it.

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 foc…

> don't expect it to load in a browser

Takes a few seconds, but otherwise seems pretty ok in desktop Safari. Preview.app also handles it fine (albeit does allocate an extra ~1-2GB of RAM)

Re: I use zip bombs to protect my server

#408

Post by PeterStuer »

thrwyep wrote: post #343
PeterStuer wrote: post #303

"On my server, I've added a middleware that checks if the current request is malicious or not" How accurate is that middleware? Obviously there are false negatives as you supplement with other heuristics. What about false positives? Just collateral damage?

I thought he maintains his own list of offenders

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

Re: I use zip bombs to protect my server

#409

Post by jsnider3 »

opan wrote: post #166
bobmcnamara wrote: post #158

Earlier quoted context omitted.

I made a 64kx64k JPEG once by feeding the encoder the same line of macro blocks until it produce the entire image. Years later I was finally able to open it.

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 foc…

I get a Your connection was interrupted on Chrome.

Re: I use zip bombs to protect my server

#410

Post by dspillett »

ycombinatrix wrote: post #15
zzo38computer wrote: post #10

I also had the idea of zip bomb to confuse badly behaved scrapers (and I have mentioned it before to some other people, although I did not implemented it). However, maybe instead of 0x00, you might use a different byte value. I had other ideas too, but I don't know how well some of them will work (they might depend on what bots they are).

The different byte values likely won't compress as well as all 0s unless they are a repeating pattern of blocks. An alternative might be to use Brotli which has a static dictionary. Maybe that can be used to achieve a high compression ratio.

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.
Post reply on HN