Exim exploit for versions prior to v4.92

KH-JonathanKW

Technical Support
Staff member
Hey folks,

There was a recent patch to a previously unknown exploit that the Exim team patched without truly knowing that they patched it.

--
https://blog.cpanel.com/exim-cve-2019-10149-protect-yourself/
--

If you're running cPanel server; chances are that you've already been patched -- as mentioned in the above article.

--
To confirm you are already running a patched version, you can run this command on the server:
rpm -q exim

The output will show you the Exim versions that are installed, and should look something like what’s below:
For Version 78: exim-4.92-1.cp1178.x86_64
For Version 80: exim-4.92-1.cp1180.x86_64
--


However; if you are on DirectAdmin; you may need to manually update as DirectAdmin does not automatically update.

You'll need to update Exim manually.

You can check Exim's version by running the following command:

--
exim --version
--

You'll receive output like so;

--
# exim --version
Exim version 4.92 #5 built 06-Jun-2019 18:11:13
--

You'll get more output than that, but the above is important and what you should pay attention too.

If the version is not 4.92; then you'll need to update!

To update DirectAdmin's Exim service you can perform the following over SSH

--
cd /usr/local/directadmin/custombuild
./build update
./build exim
--

If you get an error stating that you have not set exim configuration to be updated; then you'll do the following

--
cd /usr/local/directadmin/custombuild
./build update
./build set exim yes
./build set eximconf yes
./build set eximconf_release 4.5
./build set spamassassin yes
./build update
./build exim
--

Afterwards; just run the previous 'Exim --version' command to verify that you are on the updated version.

As always; if you would like us to check into it and/or perform the update for you -- Please open a support ticket!
 

phpAddict

Active Member
Thanks for the notice! I had:
exim-4.92-1.cp1180.x86_64 on one server
exim-4.92-1.cp1178.x86_64 on another
and exim-4.91-3.cp1170.x86_64 on a customized server currently stuck on EA3, so updates have been an issue. I modified the /etc/cpupdate.conf file per their instructions, ran the update (to v76.0.22) with no issues, changed that file back, and did a reboot for good measure. That brought it up to exim-4.91-4.cp1170.x86_64. I'd likely have to do a lot to get this server working on EA4. Is there anything I can do to update Exim without being forced to migrate to EA4? I imagine the answer is no, but figured I'd ask. With the amount of work it took to configure the server I'd rather upgrade to a newer VPS if I'll have to go through all the trouble again.
 

KH-JonathanKW

Technical Support
Staff member
According to cPanel; it should bring it up to date to the current version.

If it's not doing as they described based on their own update post; I'd suspect that something is askew and they (cPanel) would need to take a closer look at that server.

cPanel was originally never going to patch v76, so...there's no telling what occurred on their end.

You can see if perhaps they patched it but left it at 4.91; though that feels unlikely.

--
rpm -q --changelog exim | grep -i 'CVE-2019-10149'
--

In regards to the EA4 comment; most servers don't typically experience issues updating to EA4.
 

phpAddict

Active Member
@KH-JonathanKW Thanks for clarifying. Scary.
The flaw, which dates back to version 4.87 released in April 2016, is trivially exploitable by local users with a low-privileged account on a vulnerable system running with default settings. All that's required is for the person to send an email to "${run{...}}@localhost," where "localhost" is an existing local domain on a vulnerable Exim installation. With that, attackers can execute commands of their choice that run with root privileges.
Full Article
 

KH-JonathanKW

Technical Support
Staff member
It's worth noting that we pushed a patch out across the network for any older VPS's utilizing CentOS6 32bit.

exim-4.87-8.cp1156.i686.rpm has been built with the patch for CVE-2019-10149 for CentOS 6 / 32bit servers and pushed to vulnerable CentOS 6 v56 across our network.
 
Top