Use 'zmprov' (the correct command name) instead of 'zmprove' (wrong) #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Please use at least the correct command name:
zmprov. Meanwhile this advisory is also known as CVE-2022-32294.Aside of this, I'm unable to reproduce the issue. And unfortunately your description how to reproduce this possible security flaw is incomplete. Based on the official Zimbra administration guidelines, I assumed the following steps:
/var/log/secure(RHEL/Rocky Linux, or where eversudocalls are logged) – butzmprovby itself does not callsudoat all, and I can not find any hint about a password for my above example usertux@example.netin any syslog file or elsewhere within the syslog stack.Further on: If this security flaw really exists, but was just accidentially described incompletely, it mainly applies by default only to Zimbra multi-server setups with remote syslog, or to regular setups with manually configured remote syslog. On default Zimbra single-server setups without any manually configured remote syslog, the password is not transmitted to foreign systems.
Most likely the
sudocalls in your screenshot (copied in below) are caused by a third-party application, but not by Zimbra.