Open-Xchange: Privilege escalation possible in dovecot when similar passdbs are used

Summary

Privilege escalation is possible as a result of incorrect security code logic for dovecot passdb definitions.

Description

When two passdb configuration entries exist in the dovecot configuration which have the same driver and args settings, the incorrect username_filter and mechanism settings can be applied to passdb definitions. These incorrectly applied settings can lead to an unintended security configuration and can permit privilege escalation with certain configurations.

The dovecot documentation does not advise against the use of passdb definitions which have the same driver and args settings. One such configuration would be where an administrator wishes to use the same pam configuration or passwd file for both normal and master users but use the username_filter setting to restrict which of the users is able to be a master user.

Code Analysis

passdb_find() makes the incorrect assumption that if the passdb’s driver and args settings are the same, then the entire passdb is identical. This leads to the initial passdb definition and its associated settings being returned. passdb_preinit() then assumes as it has received a non-NULL passdb from passdb_find() that it does not need to set the mechanism and username_filter settings which may have been set in this passdb definition. This leads to these settings being possibly incorrect for some of the passdbs that the request authenticates against.

Then during the authentication process, auth_request_want_skip_passdb() is called and checks both the mechanism and username_filter settings. However, as a result of the incorrect logic applied within passdb_preinit() as described above, these settings are possibly incorrect.

This can lead to a non-master user achieving master user status and privileges when not intended by the configuration file or may lead to a mechanism being accepted when it should not. This happens whether using any driver including static password, passwd file and pam authentication so long as the driver and args are the same.

It is also possible that as functionality of passdbs are extended in the future this vulnerability would extend to those new areas of code if these are introduced at the same point as the username_filter and mechanism settings code.

Recommendations

Temporary workaround

• Use global ACLs to protect user accounts if not already in use
• Use different passdb configurations where driver and args settings are not identical
  ###Possible code fixes
• Remove call to passdb_find() in passdb_preinit()
• Fix passdb_find() to determine if passdb is indeed identical across all settings

Reproduction

Create directory to host files and change to this directory
Download attached F1719541 into this folder

mkdir -p etc
mkdir -p srv
docker run -d --rm --expose 993 -p 993:993 --name dovecot dovecot/dovecot
docker cp dovecot:/etc/dovecot etc
docker cp dovecot:/srv/mail srv
tar -zxvf dovecot_passdb_privilege_escalation.tar.gz
mv dovecot.conf* etc/dovecot
mv passwd etc/dovecot
tar -zxvf ../dovecot-airdrop/tests.tar.gz
docker stop dovecot
docker run -d --rm --expose 993 -p 993:993 --mount type=bind,source="/pathtofolderhostingfiles/etc/dovecot",destination="/etc/dovecot" --mount type=bind,source="/pathtofolderhostingfiles/srv/mail",destination="/srv/mail" --name dovecot dovecot/dovecot
cd tests
./dovecot_passdb_privilege_escalation.sh```

You can also use the alternative docker.conf-mechanism configuration file in place of the one used initially and see that mechanism setting is also ignored.

## Impact

As a result of this vulnerability an attacker may attempt to utilise known or weak user credentials to obtain master user privileges to access other email accounts within dovecot in case this configuration exists.

* Attack vector: The attack can be carried out over any network vector which is already open by the configuration (i.e. IMAP)
* Attack complexity: Requires certain dovecot configuration conditions to be met
* Privileges required: Existing standard user privileges are sufficient to gain escalated privileges
* User interaction: None required
* Scope: Unchanged
* Confidentiality: Once master user privileges are obtained the attacker may access other user's mail
* Integrity: Once master user privileges are obtained the attacker may delete or alter other user's mail
* Availability: May be able to use IMAP SETACL and DELETEACL commands to deny access to dovecot for other users (if imap_acl plugin is loaded and master user has suitable permissions for this)