As already outlined on https://security-tracker.debian.org/tracker/CVE-2023-42118 there's a known security issue in libspf2 found through a security review of Exim by the Zero Day Initiative. An integer underflow in libspf2 was found which can be used to perform RCEs. A patch on https://github.com/shevek/libspf2/pull/44 is available and has been merged into the main repository. All relevant links are already available on the Debian Security Tracker.
Hi, Please note that as already outlined in the security-tracker and on the upstream issue there is still no confirmation from ZDI that the two issues are the same. So no, we cannot consider the pull/44 from upstream the fix for CVE-2023-42118. Better communication on that matter from the anonymous reporter would be very helpfull to clarify the libspf2 status. Regards, Salvatore
Dear Salvatore, I don't disagree with your statement. However, many have already tried to reach ZDI and have not received clear communication. Perhaps Debain can add to the pressure to get more clarity? While the ZDI webpage on this CVE claims they contacted the developer, it's unclear whether they contacted exim or libspf2 and exactly what information they shared. However, this does not take away that the current pull request fixes a potential RCE (whether it's part of this CVE or not) that should, with some urgency, get packaged and released. Many other distros have already done so, and Debian is lagging behind. This is even more serious considering exim is the default MTA on Debian, while many other distros opt for postfix. Kind regards, Bert Van de Poel
It looks to me like the default Exim config in Debian explicitly calls /usr/bin/spfquery.mail-spf-perl from the spf-tools-perl package, not the libspf2 implementation supplied by the spfquery package. Also spf-tools-perl is suggested by exim4-base, while neither spfquery nor any other packages built from libspf2 seem to be referenced by any of the exim4 packages. I seems the only way Exim users on Debian are likely to be impacted is if they've edited their configuration to call the alternative spfquery implementation instead of the suggested one, and explicitly installed that package.
[...] Hello, You seem to be looking at old packages, perhaps oldstable? exim4-daemon-heavy in Debian 12 (bookworm) is linked against libspf2 and the default configuration has hooks to enable SPF lookups via libsp2, not spf-tools-perl. cu Andreas
Thanks, I missed that exim4-daemon-heavy has a dep on libspf2-2 as of bookworm (though exim4-base still suggests spf-tools-perl even in sid). It looks like the current Ubuntu LTS (2022.04) pre-dates this change in Debian, so Ubuntu LTS users are mostly shielded from the presumed risk for now, but you're right the concern is greater in Debian due to the recent transition.
Wednesday, 18 October 2023 11:56:01 CEST, Salvatore Bonaccorso wrote: It looks like it fixes *some* important bug, so should I make uploads with it for the time being? BTW, the same exact place in the code was the subject of CVE-2021-20314, but nobody realised that the patch applied then wasn't complete.
Hi Magnus, To expose the fix for pull/44 from upstream I would suggest to upload to unstable, but do not reference the CVE (again we have no understanding if that's the same issue). And if we want to keep this bug associated for the CVE, then neither should it be closed. FWIW, it is also mentioned in by the commiter, that "I can find one integer underflow which I've fixed with #44 but I haven't been able to get it to do anything after that because another buffer fills up." We can next then discuss if/what to do about stable and oldstable. It is as well plausible that CVE-2021-20314 was "rediscovered" or its incomplete fix. But again, without further information from the anonymous reporter to ZDI we cannot know. Regards, Salvatore
It seems this has stalled. Most distros have already released a patched version of libspf2. While I agree it's unclear whether the currently available patch fixes this CVE, it does however fix an underflow that would be relevant to release as a security fix, I think. Libspf2 has tried to reach out to Zero Day Initiative, but it seems they never got any clear and concrete response. I would suggest that Debian move ahead with this patch at least, or what is the common procedure in cases like this? Bert