[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210810122113.3fe65cc9@computer>
Date: Tue, 10 Aug 2021 12:21:13 +0200
From: Hanno Böck <hanno@...eck.de>
To: oss-security@...ts.openwall.com
Subject: STARTTLS vulnerabilities
Hi,
I wanted to share some research that we did on the security of
STARTTLS. While we didn't specifically look at open source software,
many of the vulnerabilities found are in open source mail servers and
clients:
https://nostarttls.secvuln.info/
Our starting point was an old vulnerability in Postfix [1]. In
2011 Postfix developer Wietse Venema found that it's possible to inject
plaintext content into the TCP packet of a STARTTLS command and a
server would interpret it as if it was part of the TLS session.
This command injection vulnerability was subsequently found in many
other mail servers, but as we learned it was still not fixed
everywhere. It is most severe in IMAP and SMTP/Submission servers,
where it can be used for credential stealing.
We subsequently also found that a very similar (but somewhat less
severe) vulnerability exists in mail clients that also would interpret
plaintext injected into the answer to a STARTTLS command as if they
were part of the TLS connection. We call this a response injection.
Furthermore we learned that the IMAP PREAUTH feature is problematic in
combination with STARTTLS. PREAUTH can be sent by a server in response
to a client connection to signal the client that it is already
authenticated without login credentials. However the standards say that
in an authenticated state a client cannot send a STARTTLS command. Thus
PREAUTH allows a MitM attacker to prevent STARTTLS from happening. This
was originaly found in the Trojita mail client, but we found many other
mail clients are vulnerable.
Noteworthy open source projects that were impacted by at least one of
the vulnerabilities we found include Mozilla Thunderbird, Claws-Mail,
Mutt, LibEtPan (mail protocol library used by many other clients),
Exim, Dovecot, s/qmail, Courier. Our webpage lists all the
STARTTLS vulnerabilities we found and as far as we know them the state
of fixes and CVEs.
Our focus was the communication between mail clients and servers. We
came to the conclusion that in this situation the dedicated / implicit
TLS ports (465, 993, 995) for mail protocols should be preferred as
they avoid all STARTTLS vulnerabilities and have no real downside
(it's even faster because you avoid roundtrips). Ideally STARTTLS
should be deprecated in the long term.
Communication from server to server (esp. in combionation with
MTA-STS) and STARTTLS in other protocols would be good avenues for
further research.
[1] http://www.postfix.org/CVE-2011-0411.html
--
Hanno Böck
https://hboeck.de/
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
