Bug 1187688

(In reply to Gianluca Gabrielli from comment #0)
> In sendmail v8.16.1 and v8.17.0.3 additional security checks have been
> developed to mitigate ALPACA kind of attacks.

And what does this mean or better what has to be done ... beside an already done version update?

Currently there is no offical sendmail 8.17 and above

From the changelog, I can assume the following points are the ones related to the mitigation of this attack:

8.16.1/8.16.1	2020/07/05
	SECURITY: If sendmail tried to reuse an SMTP session which had
		already been closed by the server, then the connection
		cache could have invalid information about the session.
		One possible consequence was that STARTTLS was not
		used even if offered.  This problem has been fixed
		by clearing out all relevant status information
		when a closed session is encountered.
		
8.17.1/8.17.1	202X/XX/XX
	New ruleset check_other which is called for all unknown SMTP
		commands in the server and for commands which do not
		have specific rulesets, e.g., NOOP and VERB.
	Previously the commands GET, POST, CONNECT, or USER terminate
		a connection immediately only if sent as first command.
		Now this is also done if any of these is sent directly
		after STARTTLS or if the 'h' option is set via
		srv_features.
	CONFIG: New FEATURE(`check_other') to provide a default
		check_other ruleset.

v.8.17.1 is not yet released but these changes can be found in version v.8.17.0.3 (2021-06-23).

Without the sources available via a VCS (like git) it's quite hard to cherry-pick the right changes. Sources of sendmails v8.17.0.3 can be downloaded here [0]. A comparison between v.8.15.2 and v.8.16.1 is shown here [1], which can turn out to be helpful to address the changed LOCs responsible for the mitigation of the attack.

@Werner, as maintainer of this package please help us to understand which are the affected packages and how can we backport the right changes?


[0] https://ftp.sendmail.org/snapshots/
[1] https://fossies.org/diffs/sendmail/8.15.2_vs_8.16.1/

The fix seems to be within 8.16.1 (avoid to resuse an already closed TLS session) and already part of Factory as well as  Tumbleweed. On SLES we do not use sendmail AFAIK and AFAICR ...

The changes of the upcoming 8.17.1 seems not be related with this attack vector.

And yes I know about the snapshots ... but Id like to avoid those beta state code if ever possible.

Also last time Ive tried to update sendmail on SLE-15 to get it to Leap 15 this had not worked out

Therefore I'd like to ask to be allowed to do a SR from external to internal build sever

  isc submitreq openSUSE.org:server:mail sendmail SUSE:SLE-15:Update sendmail

to get the sendmail updated on Leap 15 versions

Found differences in the submit an receive SMTP mails between 8.16.1 and the snapshot 8.17.0.3

 STLS_connection
-RSOFTWARE      $#error $@ 4.7.0 $: "403 TLS handshake."
-RDANE_FAIL     $#error $@ 4.7.0 $: "403 DANE check failed."
+RSOFTWARE      $#error $@ 4.7.0 $: "454 TLS handshake failed."
+RDANE_FAIL     $#error $@ 4.7.0 $: "454 DANE check failed."
+RPROTOCOL      $#error $@ 4.7.0 $: "454 STARTTLS failed."
+RCONFIG                $#error $@ 4.7.0 $: "454 STARTTLS temporarily not possible."


... as RSOFTWARE, RPROTOCOL and RCONFIG are new tags this might require an version update to next 8.17.1

Yet an other change ... an experimental compile option ...
means only a version update is not enough without -D_FFR_MTA_STS

+       Experimental support for SMTP MTA Strict Transport Security
+               (MTA-STS, see RFC 8461) is available when using
+               - the compile time option _FFR_MTA_STS (which requires
+                 STARTTLS, MAP_REGEX, SOCKETMAP, and _FFR_TLS_ALTNAMES),
+               - FEATURE(sts), which implicitly sets the cf option
+                 StrictTransportSecurity,
+               - postfix-mta-sts-resolver, see
+               https://github.com/Snawoot/postfix-mta-sts-resolver.git

the only question which rises ... how save this is (beside security)

SLE update problem is the jump from 8.15.2 to 8.16.1 ... likely we need to review this if we need a feature request.

(In reply to Marcus Meissner from comment #7)
> SLE update problem is the jump from 8.15.2 to 8.16.1 ... likely we need to
> review this if we need a feature request.

Do we have customers of SLE using sendmail? ... AFAICR we do only support postfix

In server:mail I now have the pre version 8.17.0.3 with enable experimental support of SMTPUTF8 (EAI, see RFC 6530-6533) as well as support for SMTP MTA Strict Transport Security ... not tested yet though

ah yes, sle15 itself only gets libmilter from sendmail package currently.

Hi Werner,

how should we proceed to fix this in SUSE:SLE-11-SP1:Update and SUSE:SLE-12:Update?

(In reply to Gianluca Gabrielli from comment #11)
> Hi Werner,
> 
> how should we proceed to fix this in SUSE:SLE-11-SP1:Update and
> SUSE:SLE-12:Update?

I'd like also update SLE-15 aka Leap 15.* with latest sendmail 8.17.1

As already asked ... do we support sendmail for SLE-11 and SLE-12? ... Beside this we should do a version update (backport causes more breakage then it solves) and we need an uptodate versions of openssl and cyrus-sasl to be safe ...

And even if it builds for SLE-11 and SLE-12 on OBS (server:mail/sendmail)
... we have there some changes in the systemd service unit files from Johannes

 Tue Nov 16 15:35:19 UTC 2021 - Johannes Segitz <jsegitz@suse.com>
 - Added hardening to systemd service(s) (bsc#1181400). Modified:
   * sendmail-client.service
   * sendmail.service

which might be a problem on SLE-11 and maybe on SLE-12

(In reply to Dr. Werner Fink from comment #12)
> (In reply to Gianluca Gabrielli from comment #11)
> > Hi Werner,
> > 
> > how should we proceed to fix this in SUSE:SLE-11-SP1:Update and
> > SUSE:SLE-12:Update?
> 
> I'd like also update SLE-15 aka Leap 15.* with latest sendmail 8.17.1
> 
> As already asked ... do we support sendmail for SLE-11 and SLE-12? 

Yes, we do support it on both codestreams. You can get this information from here [0].

> Beside this we should do a version update (backport causes more breakage
> then it solves) and we need an uptodate versions of openssl and cyrus-sasl
> to be safe ...

That sounds like a big step, let's ask @Marcus' opinion about that.


[0] https://smelt.suse.de/maintained?q=sendmail

(In reply to Dr. Werner Fink from comment #12)
https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort has a snippet that can be used to modify the service files on the fly to drop options not supported on older products

Hi Werner,

we still need the patch to be submitted to the following affected packages.

Affected and supported:
 - SUSE:SLE-11-SP1:Update/sendmail 8.14.3
 - SUSE:SLE-12:Update/sendmail     8.14.9
 - SUSE:SLE-15:Update/sendmail     8.15.2

Unsupported:
 - SUSE:SLE-11:Update/sendmail     8.14.3

Already fixed:
 - openSUSE:Factory/sendmail       8.17.1

As you can see we also need SUSE:SLE-15:Update due to the fact that it ships to openSUSE-SLE_15.3 and openSUSE-SLE_15.4.

Still my question: do we have customers out there which are using the not supported sendmail instead of postfix?  And this is a version upgrade as well!
This because this more than a simple backport of a patch.

Compare with https://security-tracker.debian.org/tracker/CVE-2021-3618
they also have this problem