Debian Exim Spool 本地root提权漏洞

Exim4 in some variants is started as root but switches to uid/gid
Debian-exim/Debian-exim. But as Exim might need to store received
messages in user mailboxes, it has to have the ability to regain
privileges. This is also true when Exim is started as "sendmail".
During internal operation, sendmail (Exim) will manipulate message
spool files in directory structures owned by user "Debian-exim"
without caring about symlink attacks. Thus execution of code as
user "Debian-exim" can be used to gain root privileges by invoking
"sendmail" as user "Debian-exim".

<a href="" rel="nofollow"></a>
demonstrates the issue using a ELF file being both executable
and shared library which is invoked multiple times by different

Results, Discussion:
As Exim4 process itself is already quite privileged - it has to
access the user mailboxes with different UIDs anyway - the having
such problems is expectable and explainable. A change in documentation
might make sense, to indicate, that the special user "Debian-exim"
is only intended to mark files being used by the daemon, but not
to provide root/daemon user privilege separation.

Even without this vulnerability, a "Debian-exim" process could
use <a href="" rel="nofollow"></a>
to escalate to "adm" group, which again makes it very likely to
use "syslog", "apache" or other components to escalate to root
via "/var/log". This is annoying, perhaps this should get a CVE
to make daemon-to-root escalations harder in general.

20160605: Discovery, report Debian security
20160607: Writeup
20160611: Also verified in Ubuntu, <a href="" rel="nofollow"></a>
20160630: Publication

* <a href="" rel="nofollow"></a>
* <a href="" rel="nofollow"></a>
* <a href="" rel="nofollow"></a>