Exim can do a lot of things, including delivery of mail to users' directories. Root privileges are required to access those directories. Oh, also ".forward" files in users' home directories.
I guess this is why Ubuntu ships exim binary with setuid bit on it
Ugh, the deliver program should be a seperate process then with some sort of privilege seperation scheme perhaps. Postfix also handles .forward files from memory, I wonder how it does it.
Maybe the Exim people don't feel like its worthwhile to rearchitect it, given that there are MTA's with more secure designs/implementations out there already.
Maybe Exim people are smarter than you give them credit for. Exim does use separate processes and privilege separation.
SMTP daemon itself does not run as root (on default Debian it runs as "Debian-exim" user). Some processes do need to run as root for local delivery, as others have mentioned.
How exactly this exploit works around that I don't know. PoC isn't public. Bugs happen, even with secure designs.
Thanks for the information, I haven't used Exim since I last used Debian where it was the default MTA in the 1990's. I wasn't trying to imply that they weren't smart. If Ubuntu has it setuid root, than that's a different issue, although I still don't see why it wouldn't drop those privileges at the earliest opportunity.
Like any MTA it needs to be root to connect to port 25. It can and does drop privilege after that. Like any MTA it needs to have a process running as root to do local deliveries as a particular user and to do .forwards . It appears that process is what is being attacked here. If you don't do local deliveries/.forwards, you don't have to have any processes running as root.
It's worth noting that as far as I can tell, Linux didn't support CAP_NET_BIND_SERVICE until 2.6.24[1], which was released in January 2008[2].
Exim itself dates from 1995[3].
I'm not really up to date on the use of capabilities, but it would seem that it can be setup before running the main processes anyway[4] using the setcap command (not sure how portable this is on other platforms, eg. BSD's) and it would appear to be a distribution/packaging issue in that context anyway.
There is also always the possibility of setting the port used for SMTP connections to a port higher than 1024 anyway, and using iptables/firewalld etc. to forward port 25 to that unprivileged port, as also discussed in [4].
Of course, neither of these options help in the specific case of needing to access user's home directories, either to read .forward files or deliver mail there directly.
Indeed. qmail describes this quite well and is portable for unix. The qmail-queue process does local deliveries, tcpserver runs against port 25 and invokes qmail-smtpd. Spending time to design software into small components pays for itself in the long run. I think qmail's downfall was that it is so stable people dind't have many issues to fix once the patches were written. It is starting to reform in 'notqmail', which I'm hoping will spar with postfix.
Indeed, kind of the point I was making, maybe not clearly enough. I don't remember the last remote root exploit discovered for Postfix, or even if there ever was one.
I guess this is why Ubuntu ships exim binary with setuid bit on it