https://nostarttls.secvuln.info/ logo NO STARTTLS Why TLS is better without STARTTLS A Security Analysis of STARTTLS in the Email Context by Damian Poddebniak1, Fabian Ising1, Hanno Bock2, and Sebastian Schinzel1 1 Munster University of Applied Sciences 2 Independent Researcher Full paper published at USENIX Security 21 Introduction Connections between email clients and servers provide two ways to be protected with TLS: While implicit TLS encrypts the connection from the start and runs on a separate port, STARTTLS provides a mechanism to upgrade existing unencrypted connections to TLS. Sometimes STARTTLS is seen as an opportunistic encryption mode that provides TLS protection only when available. This is trivially vulnerable to downgrade attacks. However, modern email clients usually have the expectation that STARTTLS is enforced, and when enabled, no unencrypted communication is possible. Upgrading connections via STARTTLS is fragile and vulnerable to a number of security vulnerabilities and attacks. We found more than 40 vulnerabilities in STARTTLS implementations. We conclude that these vulnerabilities are so common that we recommend to avoid using STARTTLS when possible. Steps of an email submission and access. From left to right: Author (Email Client), Provider, Provider, Recipient (Email Client). Attacks We assume a Meddler-in-the-Middle (MitM) attacker who can modify connections established between an email client and the email server of an provider. Stealing Login Credentials with SMTP and IMAP via Command Injection In 2011 Postfix developer Wietse Venema described a bug in STARTTLS implementations that allowed injecting plaintext commands that a server interprets as if they were part of the encrypted connection. This works by sending additional commands with the STARTTLS command to the server in the same TCP segment. We found that despite being known since 2011, this vulnerability is still very common. We found 15 vulnerable implementations, and in scans, 2% of all mail servers showed this vulnerability. This command injection can be used to steal credentials with the SMTP and IMAP protocols. Our attack requires a Meddler in the Middle (MitM) attacker that can modify network traffic and has login credentials for their own account on the same server. The attacker can inject commands that authenticate them and then start sending (SMTP) or storing (IMAP) an email. The login credentials sent by the victim will be stored in the email that the attacker can access. The command injection can also be used for a cross-protocol attack to serve HTTPS content with the mail server's certificate. Detailed descriptions of these attacks can be found in our paper. Mailbox content forgery via Response Injection We discovered an attack similar to the command injection in email client applications. We call this a response injection. This bug affected many popular mail clients, including Apple Mail, Mozilla Thunderbird, Claws Mail, and Mutt. By injecting additional content to the server message in response to the STARTTLS command before the TLS handshake, we can inject server commands that the client will process as if they were part of the encrypted connection. This can be used to forge mailbox content. IMAP connection downgrade via PREAUTH and credential-stealing with REFERRAL In the IMAP protocol, a server can signal the client in the first message that it is already authenticated via the PREAUTH command. The protocol forbids using the STARTTLS command in an authenticated state. Therefore if a client application accepts PREAUTH, it cannot enforce STARTTLS. A Meddler in the Middle attacker can use this to prevent STARTTLS from upgrading the connection and force a client to an unencrypted connection. This vulnerability was originally found in Trojita in 2014. We discovered that multiple other email client applications were vulnerable to the same bug. This bug is especially severe in combination with the IMAP features Login Referrals and Mailbox Referrals. These commands allow a server to instruct a client to log into another IMAP server. By using PREAUTH to prevent an encrypted connection, an attacker can use referrals to force a client to send credentials to an attacker-controlled server. Fortunately, the referral features are not supported by many clients. We found only one client - Alpine - vulnerable to this combination of PREAUTH and referrals. Additional Attacks We found additional attacks, whose security impact may vary for implementations. Please see our paper to learn more about these attacks. Conclusion All vulnerabilities described here rely on the transition of an insecure connection to a secure connection. Implicit TLS does not have such a transition and is therefore not vulnerable to any of these attacks. We therefore consider implicit TLS a more secure option than STARTTLS. We also point out that STARTTLS always introduces at least one extra connection round trip. So implicit TLS generally provides better performance. Impact The demonstrated attacks require an active attacker and may be recognized when used against an email client that tries to enforce the transition to TLS. We have informed all popular email client and server vendors and most issues are already fixed. We think that the demonstrated attacks would be difficult to execute on a large scale and we primarily expect them to be used in targeted attacks. As a general recommendation you should always update your software and (to also profit from faster connections) reconfigure your email client to use implicit TLS only (see below). Recommendations For Email Client Users If possible, we recommend that users check and configure their email clients to use SMTP, POP3 and IMAP with implicit TLS on dedicated ports, i.e., SMTP/Submission on port 465, POP3 on port 995, and IMAP on port 993. This is in line with already existing recommendations in RFC 8314 and was already recommended by security professionals before. Some mail service providers, notably Microsoft and Apple, do not support implicit TLS for SMTP/Submission. We recommend that users ask their mail service providers to offer the more secure implicit TLS option. For Application Developers Both email server and client applications should offer implicit TLS by default. In the long term software developers may decide to not support STARTTLS at all and thus simplify both their code and configuration dialogs and files. We recommend auditing all applications supporting STARTTLS - both on the server and the client side - for the bugs discovered. Most importantly, applications need to ensure that no unencrypted content gets processed as part of an encrypted connection. IMAP applications must make sure that they do not allow PREAUTH in combination with STARTTLS. We provide the EAST toolkit, which allows testing applications. For Mail Server Administrators Make sure your server supports implicit TLS for all supported protocols. If possible, consider disabling STARTTLS for IMAP, POP3 and SMTP submission. If you really need to support STARTTLS, we recommend testing your server with our tool for the command injection vulnerability for all supported protocols. If your server software is vulnerable, you should ask your vendor for a security update. FAQ Isn't STARTTLS insecure anyway? STARTTLS is used in two "modes", "opportunistic", and "enforced". Email clients must authenticate themselves with a username and password before submitting a new email or accessing existing emails. For these connections, the transition to TLS via STARTTLS must be strictly enforced because a downgrade would reveal the username and password and give an attacker full access to the email account. How can I test if my software is vulnerable? We provide the EAST toolkit that allows testing email clients and servers. Testing an email server for the command injection is relatively easy with our Command Injection Tester. testssl.sh (dev version) and TLS-Attacker/TLS-Scanner (starttls branch) also check for the command injection. Testing an email client is more complex, and we refer to EAST's Fake Mail Server component. Are other protocols with support for STARTTLS or similar mechanisms affected? We expect to see similar vulnerabilities in other protocols using STARTTLS, e.g., XMPP, FTP, IRC, or LDAP. Thus our recommendation to avoid STARTTLS and use implicit TLS when possible applies to those protocols as well. We encourage security researchers to look for such vulnerabilities in other protocols. Some protocols only support STARTTLS and provide no implicit TLS mechanism. We recommend that standards bodies define implicit TLS modes for these protocols and that future protocols do this by default and avoid STARTTLS completely. What about communication between email servers (MTA to MTA)? Traditionally, STARTTLS between email servers only protects against passive attacks and is vulnerable to active attacks such as STARTTLS stripping. Thus STARTTLS vulnerabilities do not give an advantage to the attacker. However, efforts like MTA-STS and DANE provide authentication mechanisms for MTA to MTA connections. Therefore server software should be investigated for STARTTLS vulnerabilities as well. Particularly relevant are the buffering bugs, which can happen both for the sending (response injection) and receiving (command injection) side of a mail server. We have found and reported some vulnerabilities in server software during our research. Currently, there is no standardized way to use implicit TLS for MTA to MTA connections. Therefore, it is not possible to avoid STARTTLS without changes to the protocol specification. How important is this? It's not the most important thing you should worry about today. How can I contact you? You can reach us via mail or twitter: * Damian Poddebniak, @dues__, poddebniak@fh-muenster.de * Fabian Ising, @Murgi, F.Ising@fh-muenster.de * Hanno Bock, @hanno, hanno@hboeck.de * Sebastian Schinzel, @seecurity, schinzel@fh-muenster.de Reported Vulnerabilities The following is a list of all STARTTLS-related vulnerabilities we found during our research. None of the issues would be present if implicit TLS would have been used exclusively. Due to different kinds of reports, not all issues are publicly documented. All issues were reported more than than 90 days ago. Email Clients As an end user, make sure to use the newest version of your email software. The following list serves as a quick check if your client is still affected. Response Injection (Buffering) Product Protocol Status Links SMTP/ Fixed in macOS High CVE-2020-9941, Apple Mail (macOS) POP3/ Sierra 10.13.6/Big Sur CVE-2021-30696 IMAP 11.4 SMTP/ Fixed in iOS/iPadOS Apple Mail (iOS/iPadOS) POP3/ 14.0 CVE-2020-9941 IMAP CVE-2020-15685, Mozilla Thunderbird IMAP Fixed in 78.7.0 Vendor advisory , Bug report (restricted) SMTP/ Fixed in 3.17.6 for Claws Mail POP3/ SMTP/POP3, See libEtPan CVE-2020-15917 IMAP for IMAP IMAP/ Mutt SMTP/ Fixed in 1.14.4 CVE-2020-14954 POP3 IMAP/ Commit/Patch, NeoMutt SMPT/ Fixed in 2020-06-19 see also POP3 CVE-2020-14954 Evolution SMTP/ Fixed in 3.36.4 CVE-2020-14928 POP3 (evolution-data-server) LibEtPan (Mail Framework for IMAP/ Fixed in repository, C Language) SMTP/ unreleased CVE-2020-15953 POP3 Exim (MTA sending) SMTP Unfixed (reported - privately) Gmail (iOS/iPadOS) SMTP/ Unfixed (reported - IMAP privately) Unfixed (reported Mail.ru, MyMail SMTP privately, report - closed as not applicable) Yandex SMTP/ Unfixed (reported - IMAP privately) PHP SMTP/ Bug report (stream_socket_enable_crypto) POP3/ Unfixed (private) IMAP Negotiation and Tampering bugs Product Description Protocol Status Links Gmail Leak of emails IMAP Fixed (retested in - (Android) 2021.07.11.387440246) Gmail (Go) Leak of emails IMAP Fixed (retested in - 2020.10.15.341102866) Samsung Leak of emails IMAP Fixed (untested) - Email Untagged Alpine responses IMAP Unknown (reported via - accepted before email) STARTTLS Untagged Trojita responses IMAP Unknown Bug report Trojita accepted before STARTTLS Server Mozilla responses prior IMAP Fixed in 78.12 CVE-2021-29969, Thunderbird to STARTTLS Vendor advisory processed STARTTLS ignored when KMail "Server SMTP Unknown Bug report requires authentication" not checked Sylpheed STARTTLS IMAP Unknown Bug report stripping OfflineIMAP STARTTLS IMAP Unknown Bug report stripping GMX / STARTTLS POP3/ Web.de Mail stripping IMAP Fixed - Collector Mail.ru, Unfixed (report MyMail, STARTTLS SMTP closed as not - Email app Stripping applicable) for Gmail Avoiding Encryption via IMAP PREAUTH Product Status Links Apple Mail (iOS Reported February 2020, /iPadOS) Re-reported August 2021, - Unfixed Mozilla Fixed in 68.9.0 CVE-2020-12398 Thunderbird Alpine Fixed in 2.23 CVE-2020-14929, Commit Mutt Fixed in 1.14.3 CVE-2020-14093 NeoMutt Fixed in Release 2020-06-19 Commit/Patch, see also CVE-2020-14093 GMX / Web.de Fixed - Mail Collector Certificate Validation Product Protocol Description Status Links OfflineIMAP IMAP Accepts untrusted Unknown Bug report certificates GMX / POP3/ Accepts untrusted Still allows Web.de Mail IMAP certificates self-signed - Collector Unknown SMTP/ Accepts untrusted (report Yandex IMAP certificates closed as - not eligible) Accepts untrusted Unknown Mail.ru, SMTP certificates (SMTP, (report - MyMail IMAP) closed as duplicate) Unknown Outlook SMTP/ Certificate hostname (report (Android & IMAP not checked (SMTP, closed as - iOS) IMAP) low/medium severity) Accepting an untrusted Geary SMTP/ certificate creates Fixed in CVE-2020-24661 IMAP a permanent trust 3.36.3 exception for all certificates Fixed in Trojita Accepts untrusted repository Trojita SMTP certificates (77ddd5d4) CVE-2020-15047 (no official releases) Only checks Ruby SMTP hostname, ignores Fixed in Bug report Net::SMTP certificate 2.7.2 signature Crashes Product Protocol Description Status Links Crash when LIST or LSUB Unknown Alpine IMAP send before STARTTLS (reported - via email) Nullptr dereference Fixed in Balsa IMAP when TLS required and 2.5.10 CVE-2020-16118 PREAUTH send Stack overflow due to Fixed in Balsa IMAP repeated BAD answer to 2.6.3 Bug Report CAPABILITY command Balsa IMAP Crash on untagged Fixed in Bug Report EXPUNGE response 2.6.3 Invalid free when no Fixed in > Evolution IMAP auth mechanisms in 3.35.91 CVE-2020-16117 greeting Miscellaneous Product Protocol Description Status Links Setup wizard in POP3 Fixed KMail POP3 defaults to unencrypted in Bug Report connections 20.08 KMail POP3 Config shows "encrypted", Fixed CVE-2020-15954 but it isn't SMTP/ Dialog loop "forces" the KMail IMAP user to accept invalid Unknown Bug Report certificates Mozilla Infinite loop when POP3 Thunderbird POP3 server replies with -ERR Unknown Bug Report to STLS command Trojita SMTP/ Hard to choose implicit Fixed Bug Report Trojita IMAP TLS due to typo (German) Trojita SMTP SMTP defaults to Unknown Bug Report Trojita plaintext on port 587 Email Servers We found 320.000 vulnerable email servers in an Internet-wide scan and conducted a coordinated disclosure involving different CERTs. It is impracticable to inform and keep track of the update process of all mail service providers on the Internet, and thus we identified and prioritized popular mail service providers. We only list these in the following table. Server issues are generally more severe than client issues. Unfortunately, no client configuration prevents server issues from being exploited, not even the usage of implicit TLS. Thus, you must ensure that your server (or your mail service provider) is not affected by STARTTLS issues. You can use our command_injection_tester tool to verify that your server is not affected by the most severe issue. Command Injection (Buffering) Product Protocol Status Links Nemesis (used by GMX / POP3/ Fixed Web.de, provider) IMAP (reported - privately) SMTP/ Fixed Interia.pl (provider) POP3/ (reported - IMAP privately) Yahoo (only MTA-to-MTA, Unfixed provider) SMTP (reported - privately) SMTP/ Unfixed Yandex (provider) POP3/ (reported - IMAP privately) s/qmail SMTP Fixed in CVE-2020-15955 4.0.09 SMTP/ Unfixed Coremail POP3/ (reported via - IMAP CERT) SMTP/ CVE-2020-29547, Citadel POP3/ Unfixed Bug report IMAP Gordano GMS POP3/ Unfixed CVE-2021-37844 IMAP Fixed in 3.1.2 recvmail SMTP (reported - privately) SmarterMail POP3 Fixed in Build CVE-2020-29548 7537 Fixed in Bug report, Burp Collaborator SMTP 2020.9.2 Vendor release notes Fixed in Dovecot SMTP 2.3.14.1 and CVE-2021-33515 2.3.15 SMTP/ Mercury/32 POP3/ Fixed in 4.90 CVE-2021-33487 IMAP QMail Toaster (1.4.1) SMTP Project - discontinued Fixed in 1.1.5 Discussion from (reported 2013, Courier POP3 privately), CVE-2021-38084, known since Fix 2013 PHP SMTP/ Bug report (stream_socket_enable_crypto) POP3/ Unfixed (private) IMAP Session Fixation Product Protocol Status Links Citadel POP3/ Reported via forum, Forum with report, IMAP unfixed CVE-2021-37845 IPswitch POP3/ Reported via Mail, CVE-2021-37846 IMail IMAP unfixed Miscellaneous Issues Product Protocol Description Status Links Nemesis (used Advertises authentication Fixed by GMX / SMTP before STARTTLS even (reported - Web.de, though it is disabled via provider) Bugbounty) Media reports Golem.de: Sicherheitsrisiko STARTTLS The Hacker News: Dozens of STARTTLS Related Flaws Found Affecting Popular Email Clients The Record: STARTTLS implementations in email clients & servers plagued by 40+ vulnerabilities SecurityLab.ru: Desiatki uiazvimostei v protokole STARTTLS zatragivaiut populiarnye pochtovye klienty LWN: STARTTLS considered harmful Bulletproof TLS Newsletter: Vulnerabilities show fragility of STARTTLS Followup research After we published our research some people found similar bugs in other protocols using STARTTLS. StartTLS in LDAP nbdkit: Reset structured replies on STARTTLS (CVE-2021-3716) fetchmail: STARTTLS session encryption bypassing (CVE-2021-39272) The website design was "stolen" from the DROWN website and slightly adapted; it was created by Sarah Madden. The logo was created by foxitalic. Logo, design, and content of this website are under a CC0 license. | Imprint First published: 2021-08-09, last changes: 2021-09-02