Timo Sirainen writes:
Although I don't use it, it's plausible the checkpassword hook is also vulnerable via the MASTER_USER environment variable:
This is one possibility, and it's the worst one because it could happen before login. But it requires two things:
auth_username_chars setting must include the characters required in the exploit, so "(){;" at least I guess. None of these characters are enabled by default. But I think some people may have set this setting to empty to allow all characters.
checkpassword must call bash, which also isn't done by default.
Another possibility is is that in some setups the password (%w) may be added to userdb fields, which ends up being exported to environment if post-login scripts are used. Again Dovecot doesn't execute shell automatically, but it may end up being executed by the configuration. So this requires a valid username + password, and ability to change the password to the bash exploit.
Thanks for confirming what I suspected, Timo. The latter, if it is at all feasible, appears to be an "inside job" type of exploit, where the exploiter already has an account but can arbitrarily change their password. It's not as serious as the pre-login one, but worth addressing if the narrow circumstances of using post-login bash scripts apply.
Joseph Tam jtam.home@gmail.com