Headline
CVE-2008-4870: 436287 – dovecot.conf is world readable
dovecot 1.0.7 in Red Hat Enterprise Linux (RHEL) 5, and possibly Fedora, uses world-readable permissions for dovecot.conf, which allows local users to obtain the ssl_key_password parameter value.
Description Kurt Seifried 2008-03-06 12:08:51 UTC
Description of problem:
The file dovecot.conf is world readable by default. This poses a potential security issue if the ssl_key_password parameter is set. Any local user would be able to view the password used to protect the SSL key file. The dovecot.conf file does not need to be world readable, dovecot functions perfectly well with /etc/dovecot.conf not being world readable. Changing the default permissions of dovecot.conf to -rw-r---- (0640) would prevent this issue and has no impact on system functionality.
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
- install dovecot
Actual results:
Expected results:
Additional info:
Comment 1 RHEL Program Management 2008-06-04 22:45:53 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Comment 3 Dan Horák 2008-06-19 17:06:58 UTC
So it will not be so easy, the deliver utility (that can be used by MTAs for optimized local delivery) can be run under different users. See #452088 for details.
Comment 8 Josh Bressers 2008-10-29 20:46:51 UTC
I’ve requested a CVE id for this.
After doing some investigation, I don’t think suggesting people use the -p option is right. This has the potential to hang a booting system while waiting for a password, no?
Is there a reason we can’t go with the file permission fix Fedora did?
Comment 9 Dan Horák 2008-10-29 21:10:27 UTC
The result in Fedora was that the permissions changes were reverted back to 0644. Unfortunately there is no guarantee how is the deliver utility run.
Yes, it is a trade between storing the password in world readable file and requirement of user interaction during startup.
Comment 10 Josh Bressers 2008-10-29 23:24:16 UTC
Just so I’m understanding this correctly. Will the bootup process hang waiting for user input if this option is used?
Comment 11 Josh Bressers 2008-10-29 23:25:20 UTC
Also, why can’t we set the configuration file to 0640 root:mail and set deliver to run sgid mail?
Comment 12 Dan Horák 2008-10-30 09:29:46 UTC
(In reply to comment #10) > Just so I’m understanding this correctly. Will the bootup process hang waiting
for user input if this option is used?
yes
Comment 13 Dan Horák 2008-10-30 09:40:10 UTC
(In reply to comment #11) > Also, why can’t we set the configuration file to 0640 root:mail and set deliver
to run sgid mail?
I think we can. I missed somehow the possibility of using sgid.
Adding new maintainer into CC.
Comment 16 Timo Sirainen 2008-11-07 13:56:06 UTC
deliver isn’t really designed to be run securely as setuid/setgid. You could have worse security holes by making it a default…
For example if you make it setgid-mail, the mail group isn’t dropped while deliver is being run. That in turn has all the same problems as http://dovecot.org/list/dovecot-news/2008-March/000060.html
I don’t really see any simple solutions for this. Perhaps the proper fix would be to add some include-file capability for dovecot.conf, so that could include dovecot-secret.conf containing the password.
Comment 17 Michal Hlavinka 2008-11-24 16:55:07 UTC
fix using setgid was reverted. New patch adds !include and !include_try directive for conf file, so password can be stored in separated root only readable file.
Comment 19 Michal Hlavinka 2008-11-25 14:32:22 UTC
Release note added. If any revisions are required, please set the “requires_release_notes” flag to “?” and edit the “Release Notes” field accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents: Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.
Comment 21 Brian Forte 2008-12-04 01:54:17 UTC
Release note updated. If any revisions are required, please set the “requires_release_notes” flag to “?” and edit the “Release Notes” field accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents: @@ -1 +1,9 @@ -Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.+Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.
+from bforte’s errata draft for 2008/12/04: https://errata.devel.redhat.com/errata/show/7790\
+A password disclosure flaw was found with Dovecot’s configuration file. If a system had the “ssl_key_password” option defined, any local user could view the SSL key password. (CVE-2008-4870)
+Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.
+To better protect even this value, however, the dovecot.conf file now supports the “!include_try” directive. The password can be placed in a file owned by, and only readable and writable by, root (ie 0600). This file can then be referenced from dovecot.conf by setting the ssl_key_password option to "!include_try [/path/to/password/file]".
Comment 23 Ryan Lerch 2008-12-04 03:29:12 UTC
Release note updated. If any revisions are required, please set the “requires_release_notes” flag to “?” and edit the “Release Notes” field accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents: @@ -1,7 +1,3 @@ -Users running dovecot with password protected ssl key are advised to store password in separated file included to dovecot.conf via !include_try directive. This password containing file should be owned by root with 0600 permissions.
-from bforte’s errata draft for 2008/12/04: https://errata.devel.redhat.com/errata/show/7790\
A password disclosure flaw was found with Dovecot’s configuration file. If a system had the “ssl_key_password” option defined, any local user could view the SSL key password. (CVE-2008-4870)
Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.
Comment 24 Michal Hlavinka 2008-12-04 14:43:06 UTC
release notes fixed because they contained wrong information
!include_try directive is used this way:
OLD way:
dovecot.conf … ssl_key_password=my_secret_but_readable_password …
NEW way:
dovecot.conf … #ssl_key_password= don’t write password here, just link file containing password !include_try file_with_password …
file_with_password can for example be /etc/dovecot.sslpassword
this new file_with_password is readable(and writable) only for root and it contains line:
ssl_key_password=my_secret_password
its *NOT* : ssl_key_password=!include_try file_with_password
Comment 25 Michal Hlavinka 2008-12-04 14:43:06 UTC
Release note updated. If any revisions are required, please set the “requires_release_notes” flag to “?” and edit the “Release Notes” field accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents: @@ -2,4 +2,4 @@
Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.
-To better protect even this value, however, the dovecot.conf file now supports the “!include_try” directive. The password can be placed in a file owned by, and only readable and writable by, root (ie 0600). This file can then be referenced from dovecot.conf by setting the ssl_key_password option to "!include_try [/path/to/password/file]".+To better protect even this value, however, the dovecot.conf file now supports the “!include_try” directive. The ssl_key_password option should be moved from dovecot.conf to new file owned by, and only readable and writable by, root (ie 0600). This file should be referenced from dovecot.conf by setting the "!include_try [/path/to/password/file]".
Comment 26 Brian Forte 2008-12-04 22:42:25 UTC
Release note updated. If any revisions are required, please set the “requires_release_notes” flag to “?” and edit the “Release Notes” field accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents: @@ -2,4 +2,4 @@
Note: This flaw did not allow the attacker to acquire the contents of the SSL key. The password has no value without the key file which arbitrary users should not have read access to.
-To better protect even this value, however, the dovecot.conf file now supports the “!include_try” directive. The ssl_key_password option should be moved from dovecot.conf to new file owned by, and only readable and writable by, root (ie 0600). This file should be referenced from dovecot.conf by setting the "!include_try [/path/to/password/file]".+To better protect even this value, however, the dovecot.conf file now supports the “!include_try” directive. The ssl_key_password option should be moved from dovecot.conf to a new file owned by, and only readable and writable by, root (ie 0600). This file should be referenced from dovecot.conf by setting the "!include_try [/path/to/password/file]" option.
Comment 29 errata-xmlrpc 2009-01-20 22:00:43 UTC
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you.
http://rhn.redhat.com/errata/RHSA-2009-0205.html