Exim RCE vulnerability [CVE-2023-42115]

@Dauser2007
why you need to downgrade ? it security issued on "4.96.0" or lower.

If some issued still not solved, you can inform Directadmin team to checking for you, if you don't know how to check.
 
F.Y.I. - Ensure /usr/sbin/exim is using latest libspf2

If it is using /usr/local/lib/libspf2.so.2 , it shall be the old one (built with DA in the past custombuild some years ago).

[root@mail ~]# ldd /usr/sbin/exim | grep -i spf
libspf2.so.2 => /usr/local/lib/libspf2.so.2 (0x00007fda2a377000)
Click to expand...

(rename the /usr/loca/lib/libspf.so.2 may not be sufficient)
 
Last edited:
@fln if you could comment on the above that would be great. We are seeing that exim is using /usr/local/lib/libspf2.so.2 and that that's a version from March 2022. Is just deleting it the right way to go about this like ccto suggested, or is there a migration script/path we should follow for this? As this is a security related issue it's quite serious for us!
 
@bertvandepoel on my servers, from CloudLinux 7 (which were installed with old CB quite a while back) to 9, Almalinux 8, 9, all can update libspf2 with yum and dnf with Epel repo. Can you update on your servers?
 
@gate2vn we're using Debian and we're still waiting for them to release patched versions of libspf2. However, if there's still local leftovers of an old version from CB in /usr/local/lib then that will take preference, which is why I asked fln for further clarification about cleaning it up.
 
fln said:
A new exim version 4.96.1 is added to our mirrors and a new version of DA is released for all release channels with default exim version set to 4.96.1.

To upgrade immediately following commands can be used da update and da build exim. CB should report Exim 4.96.1 Installed. line at the end of exim build.
Click to expand...
I tried this on CentOS 7.9 and got a new version for DA but "da build exim" gives me:
-bash: /usr/local/bin/da: No such file or directory

Should I execute this command from a specific directory?
 
Monsantosucks said:
-bash: /usr/local/bin/da: No such file or directory
Click to expand...
It could be that you have jumped multiple DA versions, in DA 1.649 da binary was moved from /usr/local/bin to /usr/bin.

Just close you SSH session and connect again for bash to notice new application location. Or you could flush bash cache with hash -r command.

Same command will work then.
 
After the update, I cannot set limits per user, why?

da.png

I restored exim.pl and it works. There are a lot of differences between the current version. E.g. something like this:

1696870702724.png
 
Last edited:
How did you restored exim.pl? Is there any place to download the older version?
 
fln said:
It could be that you have jumped multiple DA versions, in DA 1.649 da binary was moved from /usr/local/bin to /usr/bin.

Just close you SSH session and connect again for bash to notice new application location. Or you could flush bash cache with hash -r command.

Same command will work then.
Click to expand...

Our host suggested the following, and this worked for us. Now running version 4.96xxx:

cd /usr/local/directadmin/custombuild
./build update
./build exim
Click to expand...
 
ccto said:
F.Y.I. - Ensure /usr/sbin/exim is using latest libspf2

If it is using /usr/local/lib/libspf2.so.2 , it shall be the old one (built with DA in the past custombuild some years ago).

(rename the /usr/loca/lib/libspf.so.2 may not be sufficient)
Click to expand...
Moved all libspf2 stuff to a temp directory, rebuild exim and;

Code: 
ldd /usr/sbin/exim | grep -i spf
    libspf2.so.2 => /lib64/libspf2.so.2 (0x00007fad2f548000)

I can just remove these old CB libspf2 files under /usr/local/lib? Nothing else to clean up?

Code: 
2870, 2869 - Use libspf2 from OS repositories.

@fln was there any proper cleanup when switched to OS repos? This switch was only for new installations?
 
Last edited:
I tried the same, and it worked on the Centos 7 server, and one Almalinux 8 server.
The other Alma 8 server will throw an error on building Exim and shows this on the end.

Code: 
make[2]: Leaving directory '/usr/local/directadmin/custombuild/exim-4.96.1-7-g79877b70e/build-Linux-x86_64/transports'
 cc -o exim
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_dns_cache.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_dns_rr.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_log_stdio.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_request.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_response.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_server.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_strerror.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_utils.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_compile.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_dns.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_dns_resolv.o): relocation R_X86_64_32 against `.text' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_dns_zone.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_interpret.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_record.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_expand.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libspf2.a(spf_get_exp.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:636: exim] Error 1
make[1]: Leaving directory '/usr/local/directadmin/custombuild/exim-4.96.1-7-g79877b70e/build-Linux-x86_64'
make: *** [Makefile:36: all] Error 2
*** The make has failed. Exiting...

When using the ldd /usr/sbin/exim | grep -i spf command then, it points to /usr/lib64/libspf.so.2 but I have this error. If I put the 3 files back (well... 2 symlinks and 1 file), I can compile Exim again without errors, however, then the ldd command again points to the libspf.so.2 in the /usr/local/lib directory.
 
The old libspf2 library was still in my custombuild folder so i did a make uninstall and that seemed to cleaned everything up. To be sure i reinstalled libspf with dnf and then a reinstall of exim. Everything works now and linked to the correct libspf2 file
 
F.Y.I. - In my CentOS 7 dev box -

[Files, using libspf2.so.2 in ldd]
/usr/local/bin/spf_example
/usr/local/bin/spfquery
/usr/local/bin/spftest
/usr/local/bin/spfd
/usr/local/bin/spfd_static

[May be related]
/usr/local/bin/spfquery_static
/usr/local/bin/spf_example_static
/usr/local/bin/spftest_static
 
You must log in or register to reply here.
Back
Top