This vulnerability allows local attackers to escalate privileges on affected installations of Exim. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2025-30232.
This vulnerability allows local attackers to escalate privileges on affected installations of Exim. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2025-30232.
Hello,
today, 12:00 UTC we published an Exim security release: exim-4.98.1 For further details please see https://exim.org/static/doc/security/CVE-2025-26794.txt
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
On Fri, Dec 29, 2023 at 12:50:55PM -0800, Alan Coopersmith wrote: On 12/26/23 11:15, Claus Assmann wrote: On Sun, Dec 24, 2023, Marcus Meissner wrote: - CVE-2023-51765 sendmail Can you update the text for this (or point me to the proper way/persons to do this)? https://www.cve.org/CVERecord?id=CVE-2023-51765 shows: Assigner: MITRE Corporation
so you can submit updates/corrections via the web form at: https://cveform.mitre.org/ Yes please use this form, or if you do not want one of us can do it.
I did not request the sendmail and exim CVEs, also the postfix CVE seems not my proposed description, so I guess someone else requested them.
Ciao, Marcus
Happy christmas list! On 24/12/2023 12.33, Marcus Meissner wrote: On Sat, Dec 23, 2023 at 02:29:34PM +0200, Valtteri Vuorikoski wrote: On Fri, Dec 22, 2023 at 11:46:48AM +0100, Marcus Meissner wrote: Hi,
FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.
Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. Looks like exim opened a bug on this yesterday too, no sign of CVE yet: <https://bugs.exim.org/showbug.cgi?id=3063> CVEs are assigned now for:
- CVE-2023-51764 postfix - CVE-2023-51765 sendmail - CVE-2023-51766 exim
Ciao, Marcus
On Sat, Dec 23, 2023 at 02:29:34PM +0200, Valtteri Vuorikoski wrote: On Fri, Dec 22, 2023 at 11:46:48AM +0100, Marcus Meissner wrote: Hi,
FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.
Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. Looks like exim opened a bug on this yesterday too, no sign of CVE yet: <https://bugs.exim.org/showbug.cgi?id=3063> CVEs are assigned now for:
- CVE-2023-51764 postfix - CVE-2023-51765 sendmail - CVE-2023-51766 exim
Ciao, Marcus
End of life: 7/10/2024, Latest version: 4.97.1
End of life: 7/10/2024, Latest version: 4.97.1
We go public with the available fixes (addressing a subset of the issues) on Monday, Oct 2nd, 12:00 UTC.
The distribution points will be:
- git://git.exim.org branches: - spa-auth-fixes (based on the current master) - exim-4.96+security (based on exim-4.96) - exim-4.96.1+fixes (based on exim-4.96.1 with the fixes from exim-4.96+fixes) tags: - exim-4.96.1
- tarballs for exim-4.96.1: https://ftp.exim.org/pub/exim/exim4/
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE -
Hi,
The ZDI reached out multiple times to the developers regarding multiple bug reports with little progress to show for it. After our disclosure timeline was exceeded by many months, we notified the maintainer of our intent to publicly disclose these bugs, at which time we were told, "you do what you do." If these bugs have been appropriately addressed, we will update our advisories with a link to the security advisory, code check-in, or other public documentation closing the issue.
Thanks, The ZDI
-----Original Message----- From: Solar Designer <solar () openwall com> Sent: Friday, September 29, 2023 11:59 AM To: oss-security () lists openwall com Cc: ZDI Researcher Mailbox <zdi () trendmicro com> Subject: Re: [oss-security] Exim4 MTA CVEs assigned from ZDI
Hi,
Thank you for posting this, Heiko! Also thank you Markus for bringing this up in the other thread:
https://www.openwall.com/lists/oss-security/2023/09/29/3
I've attached plain text exports of the ZDI advisories to this message for archival.
Out of the Exim Bugzilla entries in Markus' message, only https://bugs.exim.org/showbug.cgi?id=3001 is currently open to the public, and it says: Bug 3001 - infoleak in SPA authenticator, client
Comment 1 Jeremy Harris 2023-05-11 20:02:32 UTC
ZDI-CAN-17433 (Trend Micro)
A crafted SPA challenge from the server can cause the client authenticator to read OOB; the data is then returned to the server.
Fix: validate the offset contained in the challenge, to avoid reading past the end of the challenge data structure.
Vulnerable since at least 4.50, probably longer.
Comment 2 Heiko Schlittermann 2023-09-29 16:01:58 UTC
should be fixed in 04107e98d58efb69f7e2d7b81176e5374c7098a3 On Fri, Sep 29, 2023 at 06:06:11PM +0200, Heiko Schlittermann wrote: the ZDI assigned multiple CVEs to the Exim-MTA and published them recently:
CVE Link Exim-Bug --------------+---------------------------------------------------------+----- CVE-2023-42114 https://www.zerodayinitiative.com/advisories/ZDI-23-1468/ 3001 fixed CVE-2023-42115 https://www.zerodayinitiative.com/advisories/ZDI-23-1469/ 2999 fixed CVE-2023-42116 https://www.zerodayinitiative.com/advisories/ZDI-23-1470/ 3000 fixed CVE-2023-42117 https://www.zerodayinitiative.com/advisories/ZDI-23-1471/ CVE-2023-42118 https://www.zerodayinitiative.com/advisories/ZDI-23-1472/ CVE-2023-42119 https://www.zerodayinitiative.com/advisories/ZDI-23-1473/
The ZDI contacted us in June 2022. We asked about details but didn't get answers we were able to work with.
Next contact with ZDI was in May 2023. Right after this contact we created project bug tracker for 3 of the 6 issues. 2 high scored of them are fixed (OOB access). A minor scored (info leak) is fixed too.
Fixes are available in a protected repository and are ready to be applied by the distribution maintainers. Are distros allowed to make their updates public as soon as they can (presumably after requesting access to the protected repository)?
I suggest that you set a specific date/time e.g. in 2 days from now when both the Exim project will make the repo and the fixed bug entries (2999 and 3000) public and distros will release updates. The remaining issues are debatable or miss information we need to fix them.
We're more than happy to provide fixes for all issues as soon as we receive detailed information. Are you actively requesting such information from ZDI now?
This looks like sloppy handling of these issues so far by both ZDI and Exim - neither team pinging the other for 10 months, then Exim taking 4 months to fix even the 2 high-scored issues it did have sufficient info on. What are you doing to improve the handling from this point on?
Thanks again,
Alexander TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
For details about what personal information we collect and why, please see our Privacy Notice on our website at: Read privacy policy<http://www.trendmicro.com/privacy>
End of life: 11/4/2023, Latest version: 4.96.2
End of life: 11/4/2023, Latest version: 4.96.2
End of life: 6/25/2022, Latest version: 4.95
End of life: 6/25/2022, Latest version: 4.95
End of life: 9/28/2021, Latest version: 4.94.2
End of life: 9/28/2021, Latest version: 4.94.2
End of life: 6/1/2020, Latest version: 4.93.0.4
End of life: 6/1/2020, Latest version: 4.93.0.4
End of life: 12/8/2019, Latest version: 4.92.3
End of life: 12/8/2019, Latest version: 4.92.3
The dmarcprocess function in dmarc.c in Exim before 4.82.1, when EXPERIMENTALDMARC is enabled, allows remote attackers to execute arbitrary code via the From header in an email, which is passed to the expandstring function.
As reported to the exim user's mailing list [1], Exim suffers from a local vulnerability where a string expansion is evaluated twice. If a local attacker were able to provide unsanitized data to a data source used by Exim for looking up a value, in certain situations, the data would be eval()'d twice. This is not remotely exploitable and requires a user account on the Exim server, and an Exim configuration that does lookups against files to which the user has edit access. The end result is that, if the conditions are true, arbitrary code could be executed as the exim user. As described in the posting:
""" The root cause of this issue is the arguments to mathematical comparison operations are expanded twice (<, <=, >, >=, =). The intent of the original code was the first expansion could (for example) lookup an item from a file. The assumption was that entry would be some form of valid integer so that value was then passed to the expand function again to do a numeric conversion of values such as 19k or 45M to integers. However, if the content of the lookup is under direct user control, they could insert something with an expansion, such as:
${run {/bin/touch /tmp/OUCH}}
Since the data is not sanitized when the second expansion occurs (intended to process numerical conversion), that command would get executed as the exim user. """
This is corrected in the Exim 4.83 release [2],[3],[4]. From the description, it looks as though every version of Exim released since 2004 is affected.
[1] https://lists.exim.org/lurker/message/20140722.152452.d6c019e8.en.html [2] http://git.exim.org/exim.git/blob/exim-483:/doc/doc-txt/ChangeLog [3] http://git.exim.org/exim.git/commitdiff/7685ce68148a083d7759e78d01aa5198fc099c44 [4] http://git.exim.org/exim.git/commitdiff/0de7239e563eff6e83c3e72d7deb9fd26a54a3a7
Heap-based buffer overflow in the dkimeximquerydnstxt function in dkim.c in Exim 4.70 through 4.80, when DKIM support is enabled and aclsmtpconnect and aclsmtprcpt are not set to "warn control = dkimdisableverify," allows remote attackers to execute arbitrary code via an email from a malicious DNS server.
The DKIM implementation in Exim 4.7x before 4.76 permits matching for DKIM identities to apply to lookup items, instead of only strings, which allows remote attackers to execute arbitrary code or access a filesystem via a crafted identity.
Format string vulnerability in the dkimeximverifyfinish function in src/dkim.c in Exim before 4.76 might allow remote attackers to execute arbitrary code or cause a denial of service (daemon crash) via format string specifiers in data used in DKIM logging, as demonstrated by an identity field containing a % (percent) character.
The openlog function in log.c in Exim 4.72 and earlier does not check the return value from (1) setuid or (2) setgid system calls, which allows local users to append log data to arbitrary files via a symlink attack.
See bug #661756 http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html
" Secondly a privilege escalation where the trusted 'exim' user is able to tell Exim to use arbitrary config files, in which further ${run ...} commands will be invoked as root.
The latter should be addressed by the patch at http://lists.exim.org/lurker/message/20101209.172233.abcba158.en.html "
There is a possible remote root flaw in Exim: http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html
We do not currently know more than is contained in this mail. We will update this bug with further information as it is discovered.
Dan Rosenberg reported that when MBX locking is enabled in exim, local users could exploit a race condition to change permissions of other non-root users' files. This could lead to a denial of service, to create new files owned by other users in unauthorized locations, or to possibly escalate privileges.
Further information is available from the upstream bug report [1] and this has been fixed upstream in exim 4.72 [2].
[1] http://bugs.exim.org/showbug.cgi?id=989 [2] http://vcs.exim.org/viewvc/exim/exim-src/src/transports/appendfile.c?r1=1.25&r2=1.26
While exim is built to support the MBX format, it is not the default for local mail delivery (Unix mailbox support is the default). This will only affect users that use the "mbxformat" option in the appendfile transport.