There has been a so-called "snapshot" release of Sendmail to deal with the SMTP Smuggling vulnerability (CVE-2023-51765) that was disclosed in late Dec 2023. It is version 8.18.0.2 and can be downloaded from https://ftp.sendmail.org/snapshots/. It was briefly mentioned on the oss-security list.

I am not sure what a "snapshot" release is in the context of Sendmail or how "snapshot" versions differ from those which are formally released. Therefore I don't know whether it is appropriate to include it in Slackware 15.0 (and current) as an update. However, at face value it appears to be something to consider given that it addresses a disclosed issue.

These are beta-versions.
8.18.X will be a full DANE versions. Currently Sendmail only use 3 1 X (Dane-EE).
We have DANE records and can send outgoing mail with DANE, but in most domain organizations don't have DANE,
NOR they have STARTTLS.
There will come new versions of sendmail this year.

TALO

Nasty exploit, Everything is impacted

Sendmail, Postifx, Exim, Gmail, Outlook, Exchange, Cisco's Email Gateway, etc etc etc

https://sec-consult.com/blog/detail/...ils-worldwide/

2 members found this post helpful.

Sendmail has released version 8.18.1 which, among other things, deals with this issue. Patrick has already added it to Slackware 15.0's extras/ series (thanks Patrick!).

However, I am not sure the Slackware ChangeLog description is completely accurate (or perhaps I am just reading it wrong). The ChangeLog states:

To me, this suggests that SMTP smuggling is resolved in 8.18 only if 'o' is present in svr_features.

In contrast, the Sendmail release notes for 8.18.1 state:


As an aside, note that the Sendmail release notes talk about the srv_features 'O' flag (capital letter oh), not a lower-case letter oh ('o') mentioned in the Slackware ChangeLog.

My reading of the Sendmail release notes suggests that the SMTP smuggling fix is enabled by default in Sendmail 8.18.1. The 'O' flag in srv_features (not a lower-case 'o') can be used to disable the fix if there is a need to continue accepting email from servers which use the <LF>.<CR><LF> mail termination sequence. In other words, without the 'O' srv_feature the smuggling issue is mitigated; if the 'O' srv_feature is set the system remains vulnerable. This seems to be the opposite of what the Slackware ChangeLog suggests.

Based on my understanding of the Sendmail release notes, I expect sendmail 8.18.1 to be immune to SMTP smuggling when installed and used with unmodified configurations (which won't include "O" in srv_features). If "O" is added to srv_features then sendmail will revert to the old behaviour of accepting LF . CRLF as the end of message (and thus be vulnerable to SMTP smuggling).

1 members found this post helpful.

Hello jwoithe,

I have installed yesterday version 8.18.1 and it seems to run OK. All parts of the documentation are present (sendmail -bt -d0.3 </dev/null)
Outgoing DANE TLSA runs (trusted) and starttls between MX's (google, outlook) is OK too.
However, a lot of the MX to MX is not so very trustfully.
So most people send UNTRUSTFULL.

TALO

I was confused on this as well. What am I supposed to configure and where to fix the problem after the update? I see "Ssrv_features" in the *.cf files but not in the *.mc/m4 files and I'd rather edit those than the .cf files directly.

The srv_features are set in the access file (/etc/mail/access) like this:
After that you need to rebuild the access database:

I will be deploying the new packages early next week. At this point, I am assuming the Sendmail release notes are correct. I therefore expect that Sendmail 8.18.1 will use the additional checks by default and no explicit configuration will be needed. From a security perspective, it certainly makes sense that the new checks are enabled by default.

The one thing I don't know is whether the srv_features flag to disable the new test is "o" (as per the Slackware ChangeLog and bathory's post above) or "O" (as implied by the Sendmail release notes.

I don't know if this will impact any on here, but it appears that email reports from Sonicwall devices are sent with bare line feeds.

I've got a ticket opened since this is impacting many sites I monitor, though I found it funny that supports initial solution was to allow bare line feeds :\

It would seem they're not aware of their own security advisories - https://blog.sonicwall.com/en-us/202...mtp-smuggling/

If there's interest in getting updated information on this I'm happy to provide it...

1 members found this post helpful.

Since updating sendmail I am also having problems with cron job output not getting mailed to me any more from the local system cron on slackware64-15.0 and a remote slackware 15 system. The local cron mails just seem to disappear with no errors anywhere, but I found errors from the remote host in my maillog today stating
The remote host is using postfix with my sendmail set up as the smart mail host.

It seems to only be affecting mails sent by cron for me.

Just a note, the following appears to resolve the issue by replacing the missing element with a space

So far there doesn't appear to be any ugly side affects aside from extra processing by Sendmail
[relay=xxx-xxx-xxx-xxx.xxx.xxxxx.com, from=<xxxx@xxxx.com>, info=Bare linefeed (LF) not allowed, where=body, status=replaced]

https://ftp.sendmail.org/RELEASE_NOTES

1 members found this post helpful.

For those who may not be aware (like me), it appears srv_features: can only be used one time

Multiple values are separated by a space

If you intend to implement both g2 and u2 the value would be