I don't know Geert... Ofc you are right, but it seems like the root owned files for an attacker shouldn't be a huge obstacle either because how Zimbra works: https://packetstormsecurity.com/files/1 ... ation.htmlghen wrote:One should wonder why most of the /opt/zimbra tree is owned - and thus writable - by the zimbra user by default.
If /opt/zimbra/jetty/webapps/zimbra/public (and the files in it) were owned by root, the impact of this exploit would have been much less, as an attacker then couldn't write any files that he can execute remotely.
As a best practice, only logs, databases, and other runtime data (like jetty workdir) should be owned by the service user, and everything else, in particular executables, owned by root.
Can Zimbra please reconsider this?
IMHO mandatory access control (like SELinux) could be one solution.
Ephemeral containers could be an another. And I know, containers are not sandboxes but 1 container / 1 component could prevent these things like a crafted zip/rar archive to write anywhere.
But let's say I implement any or both of these. None of them supported (what I pay for btw) so how should I ask for help when Zimbra has some bugs, like now it has...
So instead I'm firewalling the whole thing like hell now and after a clean reinstall I'll put a certificate based authentication or sg. similar before it. It will "hurt" in the beginning for the users but the only other option I see is... forget about Zimbra completely -> They should reconsider this too.