Is dovecot vulnerable to the shellshock/CVE-2014-6271 exploit?
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 whateverI 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@gmail.com
Am 26.09.2014 02:59 schrieb 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.htm... 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 ;-).
On 9/26/2014 6:29 AM, Philipp wrote:
Am 26.09.2014 02:59 schrieb 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.htm...
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.
On Fri, 26 Sep 2014, Stephan Bosch wrote:
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/CheckPasswordJoseph Tam jtam.home@gmail.com
On 26 Sep 2014, at 11:46, Joseph Tam jtam.home@gmail.com wrote:
On Fri, 26 Sep 2014, Stephan Bosch wrote:
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:
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.
participants (4)
-
Joseph Tam
-
Philipp
-
Stephan Bosch
-
Timo Sirainen