Is dovecot vulnerable to the shellshock/CVE-2014-6271 exploit?

[Joseph Tam]

I'm right now handling this beach-ball sized grenade, and trying to
figure out which of our services need to be locked down right away.

Since dovecot passes values via environment variables based on
user input (e.g. username, password, mailbox?) to auxilliary
executables (including possibly bash shell scripts), is dovecot
vulnerable to this exploit?

(This is not a fault of dovecot, but rather bash's inadequate handling
of environment variables.)

For example, injection of this sort

1 LOGIN (){x;}exploit-code whatever

I guess auth_username_chars would mitigate this particular attempt (assuming
it can work), but other values such as mailbox names could also be injected
post authentication.

Can someone with working knowlegde of dovecot's internals confirm/deny whether
this is a something that needs to be addressed?

Joseph Tam <jtam.home at gmail.com>

[Philipp]

Post by Joseph Tam
Since dovecot passes values via environment variables based on
user input (e.g. username, password, mailbox?) to auxilliary
executables (including possibly bash shell scripts), is dovecot
vulnerable to this exploit?

Given this article about how e.g. PHP could be vulnerable via
popen/system:
http://lcamtuf.blogspot.de/2014/09/quick-notes-about-bash-bug-its-impact.html
I can only think about sieve now, when it constructs mail and pipes that
to sendmail_path,
but I would be surprised if this is using user-input (e.g. script) in
environment variables.

I was skimming through Roundcube and didnt find something 'fishy' so
far, but that
doesnt mean there is nothing ;-).

[Stephan Bosch]

Post by Philipp

Post by Joseph Tam
Since dovecot passes values via environment variables based on
user input (e.g. username, password, mailbox?) to auxilliary
executables (including possibly bash shell scripts), is dovecot
vulnerable to this exploit?

Given this article about how e.g. PHP could be vulnerable via
http://lcamtuf.blogspot.de/2014/09/quick-notes-about-bash-bug-its-impact.html
I can only think about sieve now, when it constructs mail and pipes
that to sendmail_path,
but I would be surprised if this is using user-input (e.g. script) in
environment variables.

I don't see much of an attack vector there either. However, there are
some people that have wrapped /usr/sbin/sendmail in a shell script to
achieve some sort of custom messaging behavior. Those would be vulnerable.

Another possibility for trouble would be systems using the Pigeonhole
extprograms plugin with shell scripts.

Other than that, Pigeonhole doesn't invoke other executables while
executing a Sieve script.

Regards,

Stephan.

[Joseph Tam]

Post by Stephan Bosch
I don't see much of an attack vector there either. However, there are
some people that have wrapped /usr/sbin/sendmail in a shell script to
achieve some sort of custom messaging behavior. Those would be vulnerable.
Another possibility for trouble would be systems using the Pigeonhole
extprograms plugin with shell scripts.

Although I don't use it, it's plausible the checkpassword hook is also vulnerable
via the MASTER_USER environment variable:

http://wiki2.dovecot.org/AuthDatabase/CheckPassword

Joseph Tam <jtam.home at gmail.com>

[Timo Sirainen]

Post by Joseph Tam

Post by Stephan Bosch
I don't see much of an attack vector there either. However, there are
some people that have wrapped /usr/sbin/sendmail in a shell script to
achieve some sort of custom messaging behavior. Those would be vulnerable.
Another possibility for trouble would be systems using the Pigeonhole
extprograms plugin with shell scripts.

Although I don't use it, it's plausible the checkpassword hook is also vulnerable
http://wiki2.dovecot.org/AuthDatabase/CheckPassword

This is one possibility, and it's the worst one because it could happen before login. But it requires two things:

1. 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.
2. 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.

[Joseph Tam]

Post by Timo Sirainen

Post by Joseph Tam
Although I don't use it, it's plausible the checkpassword hook is also vulnerable
http://wiki2.dovecot.org/AuthDatabase/CheckPassword

This is one possibility, and it's the worst one because it could happen
1. 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.
2. 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 at gmail.com>