Bugzilla – Bug 1044
CVE-2010-4345 exim privilege escalation
Last modified: 2011-05-19 12:37:45 UTC
When EXIM is built without the ALT_CONFIG_ROOT_ONLY configuration option, the Exim user can create a config file with ${run...} directives that will be executed as root. It's a trivial privilege escalation. We should kill the !ALT_CONFIG_ROOT_ONLY behaviour, so that *only* the root user can specify arbitrary new configs on the command line with the -C option. For people who have a genuine need to use multiple parallel configs on the same machine, we need a way to "bless" the known configs.
Created attachment 430 [details] patch This patch kills the ALT_CONFIG_ROOT_ONLY option, by making it effectively always set and never allowing even the trusted Exim user to use arbitrary config files. It repurposes the existing ALT_CONFIG_PREFIX, rather than adding a new option and making things more complex. Instead of refusing to run with config files that don't match the prefix, Exim will simply run without root privileges. And it *will* run with root privileges when invoked with the -C option for a file which *does* match the prefix. Important user-visible changes would be: - If you previously had ALT_CONFIG_ROOT_ONLY unset (the default), then you must set ALT_CONFIG_PREFIX and use matching files if you want to use alternative config files. - If you previously had ALT_CONFIG_PREFIX set, then you should be aware that matching config files will now be invoked with root privileges regardless of the uid of the invoking user. We could change the latter so that non-root and non-exim users invoking config files in ALT_CONFIG_PREFIX are *never* granted root privs, but I'm not sure we should. Comments? We might also want to have a colon-separated list of acceptable directories. In which case perhaps it shouldn't be repurposing ALT_CONFIG_PREFIX, but should be a new, different, option? We should *also* fix the CONFIGURE_USER and CONFIGURE_GROUP options, so that the exim user/group are not permitted to own the configuration files by default either.
I found a bug in that patch; we can't just refrain from setting config_changed. That flag is used for more than the decision of whether to drop privs. It's used in child.c too. I think I'm going to end up doing a new config option TRUSTED_CONFIG_PREFIXES which is a colon-separated list of acceptable prefixes (or full filenames).
This was fixed in the 4.73 release