Exim RCE vulnerability [CVE-2023-42115]

@fln
Can I manual remove these files ? My server don't have any build script folder of libspf2 in custombuild. so I can't "make uninstall" to simple clean up this old binary anymore.
Code: 
# find /usr/local -type f -name *spf*
/usr/local/bin/spfquery_static
/usr/local/bin/spf_example
/usr/local/bin/spftest
/usr/local/bin/spfd_static
/usr/local/bin/spftest_static
/usr/local/bin/spfquery
/usr/local/bin/spfd
/usr/local/bin/spf_example_static
/usr/local/include/spf2/spf.h
/usr/local/include/spf2/spf_dns.h
/usr/local/include/spf2/spf_dns_cache.h
/usr/local/include/spf2/spf_dns_null.h
/usr/local/include/spf2/spf_dns_resolv.h
/usr/local/include/spf2/spf_dns_rr.h
/usr/local/include/spf2/spf_dns_test.h
/usr/local/include/spf2/spf_dns_zone.h
/usr/local/include/spf2/spf_lib_version.h
/usr/local/include/spf2/spf_log.h
/usr/local/include/spf2/spf_record.h
/usr/local/include/spf2/spf_request.h
/usr/local/include/spf2/spf_response.h
/usr/local/include/spf2/spf_server.h
/usr/local/lib/libspf2.so.2.1.0
/usr/local/lib/libspf2.la
/usr/local/lib/libspf2.a
 
instead of remove, I just move some libs into other place.

Code: 
cd /root
mkdir backup/
find /usr/local/lib -type f -name *libspf* -print0 | xargs -0 -I {} mv {} backup/
ldconfig -v
da build exim

Code: 
# ldd /usr/sbin/exim | grep -i spf
        libspf2.so.2 => /lib64/libspf2.so.2 (0x00007f0fb5bdb000)
I don't know it safe or not. Instead remove all files relate libspf2 compiler, Just move 3 libs to other place should be safe enought.
 
When libspf2 is installed manually it would create the following files in /usr/local:

Code: 
/usr/local/bin/spfquery
/usr/local/bin/spfquery_static
/usr/local/bin/spftest
/usr/local/bin/spftest_static
/usr/local/bin/spfd
/usr/local/bin/spfd_static
/usr/local/bin/spf_example
/usr/local/bin/spf_example_static
/usr/local/include/spf2/spf.h
/usr/local/include/spf2/spf_dns.h
/usr/local/include/spf2/spf_dns_cache.h
/usr/local/include/spf2/spf_dns_null.h
/usr/local/include/spf2/spf_dns_resolv.h
/usr/local/include/spf2/spf_dns_rr.h
/usr/local/include/spf2/spf_dns_test.h
/usr/local/include/spf2/spf_dns_zone.h
/usr/local/include/spf2/spf_lib_version.h
/usr/local/include/spf2/spf_log.h
/usr/local/include/spf2/spf_record.h
/usr/local/include/spf2/spf_request.h
/usr/local/include/spf2/spf_response.h
/usr/local/include/spf2/spf_server.h
/usr/local/lib/libspf2.so.2.1.0
/usr/local/lib/libspf2.la
/usr/local/lib/libspf2.a

Main library file /usr/local/lib/libspf2.so.2.1.0 could have different version number.

CustomBuild just stopped using manually compiled files in favor of OS provided packages. And there were no cleanup operation for the old files. Old files can be removed manually with commands:

Code: 
rm -rf /usr/local/bin/spf* /usr/local/include/spf2 /usr/local/lib/libspf2.*
ldconfig

Just make sure to recompile exim to avoid leaving it linked to libraries in /usr/local.

@jamgames2 the list of files was generated by performing manual libspf2 install on a clean system and checking what files are being created. I am surprised to see your search pattern exactly matched all the files :) .
 
Last edited:
4.96.2 has been released:

-----

Dear Exim Users,

today we released 2 more fixes for the issues mentioned in the recent
CVEs.

The current latest official release is now: exim-4.96.2

- We fixed issues with the proxy protocol.
- We fixed issues in the `dnsdb` lookup subsystem.
- The remaining issue with `libspf2`, raised as CVE against Exim, can't
be addressed by us, as it seems to happen inside the library's code.
Library fixes are available.

@Users: Please update your installations.
@Distros: We don't provide a grace period for you now, as we consider
the issues quite public already and thus we do not want to put the fixes
under embargo for additional days.

See this link for a summary: https://exim.org/static/doc/security/CVE-2023-zdi.txt

Distribution points:
--------------------
- git://git.exim.org
branches:
- exim-4.96+security (based on exim-4.96) [gpg signed]
- exim-4.96.2+fixes (based on exim-4.96.2 with the fixes from exim-4.96+fixes) [gpg signed]
tags:
- exim-4.96.2 [gpg signed]

- tarballs for exim-4.96.2: https://ftp.exim.org/pub/exim/exim4/ [gpg signed]
 
Yes, we already have packages on our mirrors for the fixes. You can use the latest builds changing exim version to 4.96.2 for security fixes only or 4.96.2-12-g29d01ae2a to get security fixes and not security fixes (code from branch exim-4.96.2+fixes).

Exim version 4.96.2-12-g29d01ae2a will be used as default in next nightly alpha release.
 
Last edited:
For those using Debian: I've been pushing a little to get an update of libspf2 out. Things are being tracked on https://security-tracker.debian.org/tracker/CVE-2023-42118 . Due to lack of movement and after a suggestion from #debian-security on OFTC, I've filed a security bug with them as well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053870 . I was told the package maintainer of libspf2 seems to be unresponsive, so I'm hoping for someone else to pick this up soon. Fingers crossed a release comes soon!
 
fln said:
changing exim version to exim-4.96.2 for security fixes only or 4.96.2-12-g29d01ae2a to get security fixes and not security fixes (code from branch exim-4.96+security).
Click to expand...
Getting confused here, what is wise ? installing 4.96.2 ?
 
@Active8 4.96.2-12-g29d01ae2a is the latest version with all security fixes + additional normal fixes if I understand correctly.

Just like 4.96.1, see post #23

I started updating with custom_versions.txt (exim:4.96.2-12-g29d01ae2a) and it works perfectly fine

Code: 
exim -bV
Exim version 4.96.2-12-g29d01ae2a #2 built 16-Oct-2023 13:52:10
 
Last edited:
Sorry for confusion, I have just edited my previous post. Exim source tarball 4.96.2-12-g29d01ae2a is code from upstream exim branch exim-4.96.2+fixes not exim-4.96+security as I wrote initially.

Please use version 4.96.2-12-g29d01ae2a. @Erulezz got it right. 4.96.2 is version with only security fixes while 4.96.2-12-g29d01ae2a is same as 4.96.2 + other fixes.
 
Richard G said:
Might be easier to declare when we can expect the security fixes in the current channel of Directadmin.
Click to expand...
Yeah why not simply push it as hotfix ?
For non critical updated (like CSS in theme) DA issues an hotfix and not for this ? make no sense.
 
Active8 said:
Yeah why not simply push it as hotfix ?
Click to expand...
Yes I agree with that. These kind of dangerous vulnerabilities shoul be fixed a.s.a.p. with a hotfix. Which was easy to do with the old style custombuild.
I thought this was also possible with this new setup. It's too dangerous to keep hanging around.
Now for 1 server I used the custom_versions.txt as @Erulezz posted, but I don't like to do custom adjustments if not needed.
 
Because:
  • fixes in 4.96.2 are not critical enough to be released ASAP
  • we are preparing for DA 1.655 RC release
  • we will lump it together with Round Cube update
  • maybe even nginx/apache if they will be releasing fixes for HTTP/2 rapid-reset soon enough
Do not get me wrong but there are a lot of people who just get thrills reading about security fixes and feel dopamine kick as soon as they upgrade their servers without actually understanding the potential attack surface. Trust me following the the whole exim RCE drama closely you would agree that one day here or there will not change much in the grand scheme of things :). For the eager ones we pushed exim versions in our files server. Everyone else will get it soon enough. I am far more concerned about the DA instances with auto-updates turned off, or admins who do not update system packages.
 
fln said:
fixes in 4.96.2 are not critical enough to be released ASAP
Click to expand...
So 9,8 is not critical enough? Hmz.
I'm not a kind of person who want's every security update immediately, but that is a very high score.
If I understand this correctly this could lead to high spam issues, maybe other things. High spam score can lead tot blacklisting of servers and hard to get off with Microsoft at least, maybe others.
So I hope you're right about the issue and will wait until the update.

I don't worry as much about auto-updates turned of or admins who don't update system packages, as that is something they choose for themselves and is part of normal maintenance. Not something external. So if things go wrong because of that, it's their own responsibility/fault.
 
According to https://www.exim.org/static/doc/security/CVE-2023-zdi.txt

If I understand right , Exim 4.96.2 shall address

#1: Subject: Improper Neutralization of Special Elements
CVSS Score: 8.1
Mitigation: Do not use Exim behind an untrusted proxy-protocol proxy
Subsystem: proxy protocol (not socks!)
Fix: a355463cf, >= 4.96.2, 4.97


#2 Subject: dnsdb Out-Of-Bounds Read
CVSS Score: 3.1
Mitigation: Use a trustworthy DNS resolver which is able to
validate the data according to the DNS record types.
Subsystem: dns lookups
Fix: f6b1f8e7d, >= 4.96.2, 4.97

---

From my understanding, we or DA probably do not use proxy for Exim

The one left is dnsdb Out-Of-Bounds , where its CVSS score = 3.1
(I just wonder what is "trustworthy DNS resolver" ? Is my own BIND DNS server trustworthy?)

Richard G said:
So 9,8 is not critical enough? Hmz.
Click to expand...
 
Last edited:
I really dont see the difference between using custom_versions or twisting DA's arm to push out a hotfix. Seems to me that admins that really care about this are going to grab it as fast as possible and not wait (like I did). Just saying
 
BillyS said:
Seems to me that admins that really care about this are going to grab it as fast as possible and not wait (like I did). Just saying
Click to expand...
I just don't like to do custom things if not needed, because one also have to change it back afterwards. Now for me it's not a big difference, did it on my main server.
But for others with lots of servers, this is a load of work, compared to auto DA update, so maybe now you understand the difference. ;)
 
You must log in or register to reply here.
Back
Top