On Fri, Dec 29, 2023, Alan Coopersmith wrote: - CVE-2023-51765 sendmail

so you can submit updates/corrections via the web form at: https://cveform.mitre.org/ Thanks for the URL, I've submitted my changes yesterday.

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

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/

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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)?

1. "sendmail through at least 8.14.7" -> sendmail up to and including 8.17.2

2. remove the seemingly unrelated reference to "Merge sendmail 8.14.8 to HEAD freebsd/freebsd-src@5dd76dd"

3. Mention that 8.18 fixes the problem: Accept only CR LF . CR LF as end of an SMTP message as required by the RFCs when the new srvfeatures option 'o' is used.

sendmail 8.18.0.2 is available at https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz.sig

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

escription: By exploiting interpretation differences of the SMTP protocol, it is possible to smuggle/send spoofed e-mails - hence SMTP smuggling - while still passing SPF alignment checks. During this research, two types of SMTP smuggling, outbound and inbound, were discovered. These allowed sending spoofed e-mails from millions of domains (e.g., admin[@]outlook.com) to millions of receiving SMTP servers (e.g., Amazon, PayPal, eBay). Identified vulnerabilities in Microsoft and GMX were quickly fixed, however, SEC Consult urges companies using the also affected Cisco Secure Email product to manually update their vulnerable default configuration.

References: https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

Hi,

On Fri, Dec 22, 2023 at 01:11:37PM +0100, Marcus Meissner wrote: On Fri, Dec 22, 2023 at 11:09:49AM +0000, Stuart Henderson wrote: On 2023/12/22 11:46, Marcus Meissner wrote: 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. I'd think that sendmail should have a CVE, too, or there could be one CVE pertaining to both Postfix and sendmail, because SEC Consult write in their blog post:

"After testing some popular e-mail software in their default configuration, it turned out that Postfix and Sendmail fulfil the requirements, are affected and can be smuggled to."

As such I'd say that both Postfix and sendmail are known to be vulnerable. I'm a little confused by sec-consult's process here. They identify a problem affecting various pieces of software including some very widely deployed open source software, go to the trouble of doing a coordinated disclosure, but only do that with...looking at their timeline... gmx, microsoft and cisco? Yes its weird.

I was also confused and actually only spotted the OSS software being affected on third read over their page.

They also reference CERT and VINCE, but at least SUSE was not pulled into the VINCE issue if there was any. (as CERT has not published anything I am not sure there was any besides the Cisco disclosure). According to the timeline, they involved CERT/CC and VINCE in August:

2023-08-17: Contacting CERT Coordination Center (CERT/CC) for further discussion with Cisco ... 2023-09-13: CERT/CC accepts the case ... 2023-11-29: CERT/CC allows public release of SMTP smuggling, since no software vulnerabilities were identified ("it's not a bug, it's a feature") ... 2023-12-18: Release date of blog post

The first timeline entry omits a bit from the text, i.e., VINCE:

"we contacted CERT/CC on 17th August to get some help for further discussion with Cisco and involve other potentially affected vendors (such as sendmail) through the VINCE communication platform." Also postfix timeline starts 4 days ago only. https://www.mail-archive.com/postfix-announce () postfix org/msg00090.html This is three days after the SEC Consult blog post.

My personal interpretation is as follows:

SEC Consult concentrated on the big email platforms, because of the potential impact. They informed platforms that could be used to perform the attack against vulnerable targets. They informed Cisco since they used an affected Cisco product and could thus be targeted (even though for Cisco this is not a vulnerability, but a feature). They involved CERT/CC and VINCE, probably with the assumption that this would result in identifying and informing affected vendors and projects. The CERT/CC and VINCE involvement resulted in "there is no vulnerability". SEC Consult publish their findings.

Now, others (including me) see this as a vulnerability affecting at least some open source email servers. SNAFU.

Cheers, Erik

On 2023/12/22 11:46, 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. I'm a little confused by sec-consult's process here. They identify a problem affecting various pieces of software including some very widely deployed open source software, go to the trouble of doing a coordinated disclosure, but only do that with...looking at their timeline... gmx, microsoft and cisco?

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.

Ciao, Marcus On Thu, Dec 21, 2023 at 02:46:56PM +0000, Claus Assmann wrote: Just for completeness: sendmail 8.18.0.2 has options to handle this too, e.g., Accept only CR LF . CR LF as end of an SMTP message as required by the RFCs when the new srvfeatures option 'o' is used.

And for those who read the source code there's also an FFR: / enable checking for "bare LF" in message / "FFRBARELF",

Just for completeness: sendmail 8.18.0.2 has options to handle this too, e.g., Accept only CR LF . CR LF as end of an SMTP message as required by the RFCs when the new srvfeatures option 'o' is used.

And for those who read the source code there's also an FFR: / enable checking for "bare LF" in message / "FFRBARELF",

ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. A MiTM attacker having access to victim's traffic at the TCP/IP layer can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.

The smcloseonexec function in conf.c in sendmail before 8.14.9 has arguments in the wrong order, and consequently skips setting expected FDCLOEXEC flags, which allows local users to access unintended high-numbered file descriptors via a custom mail-delivery program.

sendmail before 8.14.4 does not properly handle a '\0' character in a Common Name (CN) field of an X.509 certificate, which (1) allows man-in-the-middle attackers to spoof arbitrary SSL-based SMTP servers via a crafted server certificate issued by a legitimate Certification Authority, and (2) allows remote attackers to bypass intended access restrictions via a crafted client certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.

Heap-based buffer overflow in Sendmail before 8.13.2 allows remote attackers to cause a denial of service (daemon crash) and possibly execute arbitrary code via a long X- header, as demonstrated by an X-Testing header.

Unspecified vulnerability in HP-UX B.11.00 and B.11.11, when running sendmail 8.9.3 or 8.11.1; and HP-UX B.11.23 when running sendmail 8.11.1; allows remote attackers to cause a denial of service via unknown attack vectors. NOTE: due to the lack of details from HP, it is not known whether this issue is a duplicate of another CVE such as CVE-2006-1173 or CVE-2006-4434.

The version of Sendmail 8.13.1-2 on Red Hat Enterprise Linux 4 Update 4 and earlier does not allow the administrator to disable SSLv2 encryption, which could cause less secure channels to be used than desired.

The version of Sendmail 8.13.1-2 on Red Hat Enterprise Linux 4 Update 4 and earlier does not reject the "localhost.localdomain" domain name for e-mail messages that come from external hosts, which might allow remote attackers to spoof messages.

Use-after-free vulnerability in Sendmail before 8.13.8 allows remote attackers to cause a denial of service (crash) via a long "header line", which causes a previously freed variable to be referenced. NOTE: the original developer has disputed the severity of this issue, saying "The only denial of service that is possible here is to fill up the disk with core dumps if the OS actually generates different core dumps (which is unlikely)... the bug is in the shutdown code (finis()) which leads directly to exit(3), i.e., the process would terminate anyway, no mail delivery or receiption is affected."

Sendmail before 8.13.7 allows remote attackers to cause a denial of service via deeply nested, malformed multipart MIME messages that exhaust the stack during the recursive mime8to7 function for performing 8-bit to 7-bit conversion, which prevents Sendmail from delivering queued messages and might lead to disk consumption by core dump files.

Signal handler race condition in Sendmail 8.13.x before 8.13.6 allows remote attackers to execute arbitrary code by triggering timeouts in a way that causes the setjmp and longjmp function calls to be interrupted and modify unexpected memory locations.

The ClamAV Mail fILTER (clamav-milter) 0.84 through 0.85d, when used in Sendmail using long timeouts, allows remote attackers to cause a denial of service by keeping an open connection, which prevents ClamAV from reloading.

The prescan function in Sendmail 8.12.9 allows remote attackers to execute arbitrary code via buffer overflow attacks, as demonstrated using the parseaddr function in parseaddr.c.

A "potential buffer overflow in ruleset parsing" for Sendmail 8.12.9, when using the nonstandard rulesets (1) recipient (2), final, or (3) mailer-specific envelope recipients, has unknown consequences.

The DNS map code in Sendmail 8.12.8 and earlier, when using the "enhdnsbl" feature, does not properly initialize certain data structures, which allows remote attackers to cause a denial of service (process crash) via an invalid DNS response that causes Sendmail to free incorrect data.

The Sendmail 8.12.3 package in Debian GNU/Linux 3.0 does not securely create temporary files, which could allow local users to gain additional privileges via (1) expn, (2) checksendmail, or (3) doublebounce.pl.

The prescan() function in the address parser (parseaddr.c) in Sendmail before 8.12.9 does not properly handle certain conversions from char and int types, which can cause a length check to be disabled when Sendmail misinterprets an input value as a special "NOCHAR" control value, allowing attackers to cause a denial of service and possibly execute arbitrary code via a buffer overflow attack using messages, a different vulnerability than CVE-2002-1337.

Buffer overflow in Sendmail 5.79 to 8.12.7 allows remote attackers to execute arbitrary code via certain formatted address fields, related to sender and recipient header comments as processed by the crackaddr function of headers.c.

Sendmail 8.9.0 through 8.12.6 allows remote attackers to bypass relaying restrictions enforced by the 'checkrelay' function by spoofing a blank DNS hostname.

Sendmail 8.12.0 through 8.12.6 truncates log messages longer than 100 characters, which allows remote attackers to prevent the IP address from being logged via a long IDENT response.