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

> We started analyzing STARTTLS implementations in E-Mail servers and
> 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
> servers and that clients suffer from simliar vulnerabilities. We also
> found some IMAP specific vulnerabilities.

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.

> (We found a buffering bug in Yahoo's MX servers, and Yahoo is one of
> 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.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Reply via email to