Well then I guess, you need to open a feature request, or better contribute to one of the existing apps, to make it compatible with the latest Nextcloud version and/or add the features you want. And since you’re talking about clinets and use the word “we” quite often, I guess this instance is used commercialy, so there’s of course always the possibilty to hire a developer that does it for you.
Maybe you should elaborate a bit what exatley happens and how those files got created and uploaded, because I cannot reproduce this. I just uploaded a few files I created two weeks ago, and Nextcloud’s WebUI says “Modified 2 weeks ago”
Why the **** are you only mentioning this as a side note now, when it’s actually the main issue, and the whole discussion about unzipping files on Nextcloud is really just about testing whether it would help work around the main issue, which it probably won’t, and if it would it would be a bad way to work around a problem that shouldn’t exist in the first place.
but we’ve seen so many solutions for that since 10 or 20 years.
it will take some effort, same as on mailserver etc. but if one DOES it, it is OK. Especially if “good enough” is enough.
and many of the remaining same security weaknesses are ones that are in NC in general and it would not hurt to start looking into them
for zips, it’s like on a mailserver, one can do things like:
extract with a different user
i.e. attach a small ramdisk with limits, extract there, move over, remove ramdisk - (a docker sidecar with auomatic restart in today’s terms)
extract in a retricted container
extract into some virtual filesystem and put a pipe’d dd size=1024K count=512 in the middle of it to simply don’t process as many chars are in a larger file
use some broker daemon that accepts the file and passes it to a scanner and then to a process that extracts it and surveil both
just LIST THE DAMN ZIP FILE and check how much is inside, don’t process that output in a stupid way.
have proper audit logs so admins can trace if it was an attack by a valid user and gauge if they did it intentionally or were trapped
use a lightweight isolation like nsjail when not in docker
i say that as someone who linked to file:///dev/zero on their blog to annoy their friends - the point being, it goes both ways, we are not helpless. it’s a design issue for sure, but there are a million of those and a solution could copy over to solve many.
I would like most of this process to be involved in any object received and then it would probably cut out a ton of attack surface.
The idea that this cannot be integrated because it is so easy to exploint (but the users should extract the thing on their computer) is a false friend IMO. The interesting question is how to make it safe(r) for the system as a whole if it happens, and from there you get to a better handling of other uploads, safer startup with a full disk etc.
Yes, but that’s a completely different and very specific use case, and maybe it could be a legitimate feature request for allowing the mail app to open zip file in a very limited scope.
Although even for that usecase, I think there are better ways to handle atachements than using zip files. For example, by stripping out the attachments from the email, and adding a downliad link to the emails instead, before delivering them to the users inboxes.
Of course, this would have to be implemented on the mail server stack or the security solution used on it, where there usually isn’t a webinterface, where end-users could directly extract these zip files. If at all they can download them from a webmail client to ther computer, which doesn’t cause the same security implications as extracting them directly in a web application.
And in general, I can only repeat that if this were to be implemented, it would have to be done very carefully, and while your concepts of how to implement this in theory may all be good, in practice there are sometimes much simpler reasons why it is not done.
One reason could simply be the resources it ties up. Implementing a feature is one thing, but after that it also needs to be maintained. Also, Nextcloud is not built from scratch, a lot of it is based on Symfony, so there may be technical limitations as well.
But feel free to let the developers know your suggestions directly by opening a detailed feature request on GitHub, or if you are a developer yourself, maybe even provide the code via pull request, or maybe better as a separate app.
I described it as it showed up for us: this seemed like a minor prob for my client (that mod dates are uploading dates) – main issue was that client wants to upload + unzip ZIPs…
But now main issue is rather that Plesk firewall or whatever puts any users IP on blocked IPs pretty fast, and I try to figure out, why. Deactivate “mod security” and / or “recidive”? Deactivate it entirely?
Maybe this issue is causing the mod date issue as well…