421–430 of 467 posts
Earlier quoted context omitted.
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.
Then you kill your service which might also be serving legitimate users.
Eg if you fork for every request, that process only serves that one user. Or if you can restart fast enough.
I'm mostly inspired by Erlang here.
> At my old employer, a bot discovered a wordpress vulnerability and inserted a malicious script into our server I know it's slightly off topic, but it's just so amusing (edit: reassuring) to know I'm not the only one who, after 1 hour of setting up Wordpress there's a PHP shell magically deployed on my server.
Yes, never self host Wordpress if you value your sanity. Even if it’s not the first hour it will eventually happen when you forget a patch.
Earlier quoted context omitted.
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.
While that is true, I recommend on the request anyway, because it makes it abundantly clear to the programmer that requests can fail, and failure needs to be handled somehow – even if it's by killing and restarting the process.
You need that to protect against not only these types of shenanigans, but also large or slow responses.
Earlier quoted context omitted.
What are you talking about? You get a compressed file. You start decompressing it. When the amount of bytes you've written exceeds some threshold (say 5 megabytes) just stop decompressing, discard the output so far & delete the original file. That is it.
Those files are designed to exhaust the system resources before you can even do these kinds of checks. I'm not particularly familiar with the ins and outs of compression algorithms, but it's intuitively not strange for me to have a a zip that is carefully crafted so that memory and CPU goes out the window before any check can be done. Maybe someone with more experience can give mode details. I'm sure though that if i…
It's intuitively extremely strange to me!
Even ignoring how zips work: Memory needs to be allocated in chunks. So before allocating a chunk, you can check if the new memory use will be over a threshold. CPU is used by the program instructions you control, so you can put checks at significant points in your program to see if it hit a threshold. Or you can have a thread you kill after a certain amount of time.
But the way zips do work makes it a lot simpler: Fundamentally it's "output X raw bytes, then repeat Y bytes from location Z" over and over. Abort if those numbers get too big.
IsMalicious() doing some real heavy lifting in that pseudo code. Would love to see a bit more under THAT hood.
Earlier quoted context omitted.
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.
That is not the case in this context. robots.txt is the only thing that specifies the document URL, which it does so in a "disallow" rule. The argument that they did not know the request would be responded to with hostility could be moot in that context (possibly because a "reasonable person" would have chosen not to request the disallowed document but I'm not really familiar with when that language applies).
> by deleting local files for example
This is a qualitatively different example than a zip bomb, as it is clearly destructive in a way that a zip bomb is not. True that a zip bomb could cause damage to a system but it's not a guarantee, while deleting files is necessarily damaging. Worse outcomes from a zip bomb might result in damages worthy of a lawsuit but the presumed intent (and ostensible result) of a zip bomb is to effectively cause the recipient machine to involuntarily shut down, which a court may or may not see as legitimate given the surrounding context.
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…
https://blog.haschek.at/2017/how-to-defend-your-website-with...
This post is suspiciously similar to my post from 2017 "How to defend your website with ZIP bombs" https://blog.haschek.at/2017/how-to-defend-your-website-with...