diff options
| -rw-r--r-- | NEWS | 6 | ||||
| -rw-r--r-- | fetchmail-SA-2021-02.txt | 32 | ||||
| -rw-r--r-- | pop3.c | 74 |
3 files changed, 69 insertions, 43 deletions
@@ -101,9 +101,13 @@ fetchmail-6.4.22 (not yet released): TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. The paper did not mention fetchmail. -* On IMAP connections, --auth ssh no longer prevents STARTTLS negotiation. +* On IMAP and POP3 connections, --auth ssh no longer prevents STARTTLS + negotiation. * On IMAP connections, do not permit to override a server-side LOGINDISABLED with --auth password any more. +* On POP3 connections, the possibility for RPA authentication (by probing with + an AUTH command without arguments) no longer prevents STARTTLS negotiation. +* For POP3 connections, RPA is only attempted if the authentication type is any. # BUG FIXES: * On IMAP connections, when AUTHENTICATE EXTERNAL fails and we have received the diff --git a/fetchmail-SA-2021-02.txt b/fetchmail-SA-2021-02.txt index c660b4aa..ffa2a3d4 100644 --- a/fetchmail-SA-2021-02.txt +++ b/fetchmail-SA-2021-02.txt @@ -3,7 +3,7 @@ fetchmail-SA-2021-02: failure to enforce STARTTLS session encryption Topics: fetchmail fails to enforce an encrypted connection Author: Matthias Andree -Version: 0.2 +Version: 0.3 Announced: TBC Type: failure to enforce configured security policy Impact: fetchmail continues an unencrypted connection, @@ -32,6 +32,9 @@ Corrected in: TBC Git commit hash (both needed) 2021-08-10 initial report to maintainer 2021-08-10 0.1 first draft 2021-08-13 0.2 mention --auth ssh defeated STARTTLS +2021-08-14 0.3 mention POP3 RPA defeated STARTTLS, and + make explicit that --auth ssh applied to + IMAP and POP3 alike. 1. Background @@ -60,17 +63,24 @@ a clear-text protocol exchange and then requesting a TLS negotiation in-band. IMAP also supports sessions that start in "authenticated state" (PREAUTH). In this latter case, IMAP (RFC-3501) does not permit sending STARTTLS negotiations, which are only permissible in not-authenticated state. - -In such a combination of circumstances (1. IMAP protocol in use, 2. the server -greets with PREAUTH, announcing authenticated state, 3. the user configured TLS -mandatory, 4. the user did not configure "ssl" mode that uses separate ports -for implicit SSL/TLS), fetchmail 6.4.21 and older continues with the -unencrypted connection, rather than flagging the situation and aborting. + In such a combination of circumstances (1. IMAP protocol in use, 2. the +server greets with PREAUTH, announcing authenticated state, 3. the user +configured TLS mandatory, 4. the user did not configure "ssl" mode that uses +separate ports for implicit SSL/TLS), fetchmail 6.4.21 and older continues +with the unencrypted connection, rather than reporting and aborting. + +A similar situation is encountered for POP3: if the remote name contains +@compuserve.com, the server supports a non-standard "AUTH" command without +mechanism argument and responds with a list that contains "RPA" (also in +mixed or lower case), then fetchmail will not attempt STARTTLS. While the +password itself is then protected by the RPA scheme (which employs MD5 however), +the session as a whole is not protected by TLS. Also, a configuration containing --auth ssh (meaning that fetchmail should not authenticate, on the assumption that the session will be pre-authenticated for -instance through SSH running a PREAUTH mail server with --plugin, or TLS client +instance through SSH running a mail server with --plugin, or TLS client certificates), will also defeat STARTTLS as result of an implementation defect. +This affected both POP3 and IMAP. This can cause e-mail and in the first case, also potentially passwords, to be exposed to eavesdropping. @@ -89,10 +99,10 @@ https://gitlab.com/fetchmail/fetchmail/-/tree/legacy_64 (primary) https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/ (copy) -3b. Alternatively, where the IMAP server supports this form of access, +3b. Alternatively, where the IMAP or POP3 server supports this form of access, fetchmail can be configured to "ssl" mode, meaning it will connect to -a dedicated port (default: 993 for IMAP) and negotiate TLS without -prior clear-text protocol exchange. +a dedicated port (default: 993 for IMAP, 995 for POP3) and negotiate TLS +without prior clear-text protocol exchange. Also, --ssl can be given on the command line, which switches all configured server statements to this ssl mode. @@ -332,9 +332,6 @@ static int pop3_getauth(int sock, struct query *ctl, char *greeting) } peek_capable = 0; } - if (ctl->server.authenticate == A_SSH) { - return PS_SUCCESS; - } #ifdef SDPS_ENABLE /* @@ -348,33 +345,6 @@ static int pop3_getauth(int sock, struct query *ctl, char *greeting) switch (ctl->server.protocol) { case P_POP3: -#ifdef RPA_ENABLE - /* XXX FIXME: AUTH probing (RFC1734) should become global */ - /* CompuServe POP3 Servers as of 990730 want AUTH first for RPA */ - if (strstr(ctl->remotename, "@compuserve.com")) - { - /* AUTH command should return a list of available mechanisms */ - if (gen_transact(sock, "AUTH") == 0) - { - char buffer[10]; - flag has_rpa = FALSE; - - while ((ok = gen_recv(sock, buffer, sizeof(buffer))) == 0) - { - if (DOTLINE(buffer)) - break; - if (strncasecmp(buffer, "rpa", 3) == 0) - has_rpa = TRUE; - } - if (has_rpa && !POP3_auth_rpa(ctl->remotename, - ctl->password, sock)) - return(PS_SUCCESS); - } - - return(PS_AUTHFAIL); - } -#endif /* RPA_ENABLE */ - /* * CAPA command may return a list including available * authentication mechanisms and STLS capability. @@ -500,7 +470,49 @@ static int pop3_getauth(int sock, struct query *ctl, char *greeting) } /* maybe_starttls() */ #endif /* SSL_ENABLE */ - /* + if (ctl->server.authenticate == A_SSH) { + return PS_SUCCESS; + } + +#ifdef RPA_ENABLE + /* XXX FIXME: AUTH probing (RFC1734) should become global */ + /* CompuServe POP3 Servers as of 990730 want AUTH first for RPA */ + if (strstr(ctl->remotename, "@compuserve.com") + && ctl->server.authenticate == A_ANY) + { + /* AUTH command should return a list of available mechanisms. */ + /* 2021 update: it is unclear which software still supports RPA these days. + This behavior (AUTH without a method argument, to query) + is not sanctioned by RFC-1734 but was/is apparently + supported by Compuserve and Microsoft for their NTLM: + https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pop3/cb6829e1-d6f4-447b-9092-2671a257563c + */ + if (gen_transact(sock, "AUTH") == 0) + { + char buffer[10]; + flag has_rpa = FALSE; + int err; + + while ((err = gen_recv(sock, buffer, sizeof(buffer))) == 0) + { + if (DOTLINE(buffer)) + break; + if (strncasecmp(buffer, "rpa", 3) == 0) + has_rpa = TRUE; + } + if (err) { + return err; + } + if (has_rpa && !POP3_auth_rpa(ctl->remotename, + ctl->password, sock)) + return PS_SUCCESS; + } + + return PS_AUTHFAIL; + } +#endif /* RPA_ENABLE */ + +/* * OK, we have an authentication type now. */ #if defined(KERBEROS_V4) |