Hacker News Reader

Comment by beautifulfreak | Hacker News Reader

As stated in the initial bug report by Zerons, an unauthenticated remote attacker could send a malicious SNI ending in a backslash-null sequence during the initial TLS handshake, which causes a buffer overflow in the SMTP delivery process. This would allow an attacker to inject malicious code that Exim then arbitrarily executes as root. This vulnerability does not depend on the TLS library in use, so both GnuTLS and OpenSSL are affected.

https://www.tenable.com/blog/cve-2019-15846-unauthenticated-...

View on HN

Why is exim running as root at that point? At least that is the question in my mind. Once it has bound to the port it should setuid() or seteuid() to a less privileged UID, unless I'm mistaken.

Granted, there will still be the possibility of remote code execution as a non-root user, but at least you're not handing an attacker root privileges by default.

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.

Here is an explicit discussion of how Exim handles this sort of issue:

* https://www.exim.org/exim-html-3.20/doc/html/spec_55.html

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.

You shouldn't use root to bind to port 25; just the capability CAP_NET_BIND_SERVICE

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.

[1] https://stackoverflow.com/questions/413807/is-there-a-way-fo...

[2] https://lwn.net/Articles/266521/

[3] https://en.wikipedia.org/wiki/Exim#Origin

[4] https://security.stackexchange.com/questions/71922/postfix-m...

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.

The most we know yet is this post:

https://www.openwall.com/lists/oss-security/2019/09/07/2

That implies it is the processing from the spool that is at fault; something is serialized and later read back.

Or use Postfix, it is separated this way.

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.

Why I still love qmail.

Why not use capabilities instead? Then root privileges are not required.

Why does it even need to presumably parse escape sequences in an SNI? AFAIK that extension holds a hostname and nothing else, and is length-delimited anyway. I'd consider the buffer overflow merely a side-effect of what is really a fundamentally wrong design decision leading down a codepath that should've never been reached in the first place.

It doesn't, it serializes the SNI name by applying backslash escaping, but fails to escape the escape character, and then incorrectly parses that serialized form.

Reply on news.ycombinator.com