Problem description:

Exim4 in at least the variant exim4-daemon-light on Debian Jessie, 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.

To gain root privileges, creation of a dual-use binary was attempted, so that the binary can both be a normal command line executable but also work as a replacement for libpam, the target for escation. Escalation procedure is as follows:

• Get current properties of /lib/x86_64-linux-gnu/libpam.so.0.83.1 for restoration later on
• Fork a sendmail instance to deliver an empty message
• Wait for appearance of a /var/spool/exim4/msglog/xxxxxx-xxxxxx-xx file
• Symlink /var/spool/exim4/input/xxxxxx-xxxxxx-xx-J to /lib/x86_64-linux-gnu/libpam.so.0.83.1 on Debian Jessie
• Wait for libpam.so.0.83.1 to change ownership
• Preserve content of libpam.so.0.83.1
• Replace libpam.so.0.83.1 with content of exploit binary
• Start /bin/su to load shared library, make exploit binary also a SUID binary
• Restore libpam.so.0.83.1 and attributes
• Invoke exploit to start root shell

The steps from above were all added to EximUpgrade.c for demonstration.

# pwd /var/spool/exim4 # /usr/bin/id uid=106(Debian-exim) gid=112(Debian-exim) groups=112(Debian-exim) # gcc -fPIC -shared -Xlinker -init=_libInit -Xlinker '--soname=LIBPAM_1.0' -Xlinker --default-symver -o EximUpgrade EximUpgrade.c -Wl,-e_entry # ./EximUpgrade --Upgrade Relinked /var/spool/exim4/input/1ayy0X-0000O3-HI-J Target ready for writing uid=0(root) gid=0(root) groups=0(root),112(Debian-exim) # ...

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 the SetgidDirectoryPrivilegeEscalation 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".

• 20160605: Discovery, report Debian security
• 20160607: Writeup
• 20160611: Also verified in Ubuntu, bug 1580454
• 20160630: Publication
• 20161225: Fixed in Exim release: link

• POC: EximUpgrade.c
• Exploit-DB: 40054