Subject: [Uta] STARTTLS vulnerabilities

From: Hanno Böck <[email-masked]>
Date: Wed, 11 Aug 2021 17:42:40 +0200

Hi,

I wanted to share some research we have done on vulnerabilities in
STARTTLS implementations:
https://nostarttls.secvuln.info/

We started analyzing STARTTLS implementations in E-Mail servers and
clients based on the 2011 command injection discovered in Postfix. We
learned that this vulnerability is still very prevalent in current
servers and that clients suffer from simliar vulnerabilities. We also
found some IMAP specific vulnerabilities.

Focussing on client-to-server communication our recommendations are
mostly in line with what this working group has already concluded in
RFC 8314, which is that implicit TLS on its own port should be
preferred over STARTTLS.

Our research has not focussed on the server-to-server part. Still I
think particularly the buffering / injection vulnerabilities are
a concern if one wants to secure s2s communication with mechanisms like
MTA-STS. I strongly recommend that users of MTA-STS audit their
STARTTLS implementations for buffering bugs.
(We found a buffering bug in Yahoo's MX servers, and Yahoo is one of
the companies driving MTA-STS. I was unable to report this properly to
Yahoo, I reported it through their Hackerone bugbounty program, but the
bug triagers were unwilling to try to understand the issue and didn't
forward it to Yahoo.)

-- 
Hanno Böck
https://hboeck.de/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Aug 2021 14:44:37 -0400

On Wed, Aug 11, 2021 at 05:42:40PM +0200, Hanno Böck wrote:

> clients based on the 2011 command injection discovered in Postfix.

Specifically discovered by Wietse Venema, while refactoring some Postfix
code.  He observed that the issue was likely not Postfix-specific, and
can affect any STARTTLS stack in which buffering happens above the
underlying I/O stack, and persists across STARTTLS.  The Postfix
exposure was addressed back in 2011, and a broader advisory was
published at the time, which noted out potential exposure in other
systems.

> We learned that this vulnerability is still very prevalent in current

What's new here, is largely a survey to see whether the issue Wietse
observed and reported in 2011 has at this point been attended to in
various other products, plus a more detailed exploration of how any
still vulnerable systems can be abused.

> Our research has not focussed on the server-to-server part.

By and large the extant MTAs were either immune by (accidental) virtue
of the internal I/O layering design, or were remediated circa 2011.

> Still I think particularly the buffering / injection vulnerabilities
> are a concern if one wants to secure s2s communication with mechanisms
> like MTA-STS.

MTA-STS is very thinly deployed, and many deployments have remained in
"testing" mode (for multiple years) to this day:

    $ curl -sLo - https://mta-sts.yahoo.com/.well-known/mta-sts.txt
    version: STSv1
    mode: testing
    mx: *.am0.yahoodns.net
    mx: *.mail.gm0.yahoodns.net
    mx: *.mail.am0.yahoodns.net
    max_age: 86400

Legitimate sending MTAs that validate Yahoo's (or other) MTA-STS
policies are not exposed to this issue, unless their own (client SMTP)
stack has STARTTLS buffering problems, in which case some forged
cleartext could be pipelined (by an MiTM) with the server's cleartext
STARTTLS command response.

> I strongly recommend that users of MTA-STS audit their STARTTLS
> implementations for buffering bugs.

The issue isn't particularly MTA-STS specific, it should be addressed
whether or not MTA-STS is supported.

> the companies driving MTA-STS.

I wouldn't exactly call staying in testing mode for ~3 years "driving".

> I was unable to report this properly to Yahoo, I reported it through
> their Hackerone bugbounty program, but the bug triagers were unwilling
> to try to understand the issue and didn't forward it to Yahoo.)

Yahoo appears to be "on life support", so I'm not surprised if there is
little movement on technical issues.

-- 
    Viktor.