7 ms·

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 init

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-remote-command-execution-flaw-disclosed-for-exim https://www.tenable.com/blog/cve-2019-15846-unauthenticated-...

nineteen999 7y ago
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.
- tryauuum 7y ago
  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
  - nineteen999 7y ago
    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.
    - avian 7y ago
      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.
      - nineteen999 7y ago
        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.
        upofadown 7y ago
        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 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.
        daurnimator 7y ago
        You shouldn't use root to bind to port 25; just the capability CAP_NET_BIND_SERVICE
        nineteen999 7y ago
        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-for-non-root-processes-to-bind-to-privileged-ports-on-linux https://stackoverflow.com/questions/413807/is-there-a-way-fo... [2] https://lwn.net/Articles/266521/ https://lwn.net/Articles/266521/ [3] https://en.wikipedia.org/wiki/Exim#Origin https://en.wikipedia.org/wiki/Exim#Origin [4] https://security.stackexchange.com/questions/71922/postfix-master-running-as-root https://security.stackexchange.com/questions/71922/postfix-m...
  - netsec_burn 7y ago
    Why not use capabilities instead? Then root privileges are not required.
- deleted 7y ago
  [deleted]
userbinator 7y ago
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.
- florz 7y ago
  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.

nineteen999 7y ago

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.

tryauuum 7y ago
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
- nineteen999 7y ago
  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.
  - avian 7y ago
    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.
    - nineteen999 7y ago
      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.
      - upofadown 7y ago
        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 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.
        daurnimator 7y ago
        You shouldn't use root to bind to port 25; just the capability CAP_NET_BIND_SERVICE
        nineteen999 7y ago
        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-for-non-root-processes-to-bind-to-privileged-ports-on-linux https://stackoverflow.com/questions/413807/is-there-a-way-fo... [2] https://lwn.net/Articles/266521/ https://lwn.net/Articles/266521/ [3] https://en.wikipedia.org/wiki/Exim#Origin https://en.wikipedia.org/wiki/Exim#Origin [4] https://security.stackexchange.com/questions/71922/postfix-master-running-as-root https://security.stackexchange.com/questions/71922/postfix-m...
- netsec_burn 7y ago
  Why not use capabilities instead? Then root privileges are not required.
deleted 7y ago
[deleted]

userbinator 7y ago

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.

florz 7y ago
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.