61–70 of 138 posts
Earlier quoted context omitted.
Why would Chrome automatically begin unzipping the file? I'm afraid to even download it now...
I accidentally downloaded it without realising this. I'd assume it performs malware scanning. Luckily I was able to end the process from the chrome task manager (shift+escape) without disrupting the rest of the browser.
Earlier quoted context omitted.
This file exploits the zip container format, not the actual compression algorithm. SSH only uses the latter, not the former, so it is not applicable.
Would it be possible to do it just exploiting the algorithm?
Earlier quoted context omitted.
> 1. You put it in a URL marked as "noindex-nofollow". Better yet, mark it Disallow in robots.txt - to see "noindex, nofollow", they'd still need to request the URL, running the risk to be served with the bomb. > 2. You create an exception so that they never cache the page and don't proxy this exact URL. They work as reverse proxies on host-basis, I don't think you can exclude a single URL. CF at least will never cac…
I put, as a test and for fun, a "Disallow" entry in my robots.txt (with a campy name to be honest) and not a single crawler hit that dir in more than three years, don't know if others had the same experience.
My experience is that most bots just hit the usual suspects, /wp-login.php, /phpmyadmin/ etc, regardless whether they are in robots.txt or not.
Earlier quoted context omitted.
You don't. Though to Apple's credit, users who are concerned with verifying checksums probably overlap with those that take cursory steps to harden their browser by, among various steps, disallowing Safari to open "safe" documents (that's what they're called in Safari's option).
Would it be prejudice to think that the checksum verifying users are not using safari?
Are you able to theoretically look at compressed data without size Metadata and estimate its final size without actually uncompressing it?
If the goal is to avoid zip bombs you can't get any more sloppy than that because then an attacker could exploit inaccuracies in your estimator.
It's not yet open-sourced but it has defenses against excessive compression ratios, mismatching local and central directory headers, ambiguous filenames, directory traversals and symlink traversals, and anything ambiguous that could exploit differences in zip implementations, e.g. some zip implementations decode from the front while others decode from the back. Most importantly, it balks at deviations from the zip format, including any kind of overlapping or sparseness, buffer bleeds etc.
At least it detected all three of the author's samples as malicious.
Earlier quoted context omitted.
If windows defender breaks scanning when it encounters a zip bomb, could that be used to mask malware later in the file?
It probably flags it as unsafe and triggers smart screen. Meaning you have to go out of your way to use the file. As for malware that would be unzipped when using an external zip file; first you would need to trigger the zip bomb on defender but not the external tool, and second defender will still scan the individual files getting unziped by that tool.
I remember being so excited when the zip format came out. Prior to zip, we suffered with the arc format. At 2400 baud, the difference in compression was very very significant.