1439137 - Bad handling of authentication failure (on Yahoo)

Status: RESOLVED DUPLICATE of bug 1408610

(Thunderbird :: Security, defect)

Description

[julien.coloos]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158

Steps to reproduce:

Try to login using AUTH method (AUTHENTICATE PLAIN) with bad login/password on Yahoo.
(I guess the same should happen with other sites, since only standard commands/authentication methods are used)


Actual results:

The server denies login and reports the issue as an IMAP "NO" response.

e.g. on Yahoo, a manual test:
A0 AUTHENTICATE PLAIN
+ 
... (authentication information)
+ eyJzdGF0dXMiOiJzZXJ2ZXJfZXJyb3IiLCJzY2hlbWUiOiJiYXNpYyIsInNjb3BlIjoiaHR0cHM6Ly9tYWlsLnlhaG9vLmNvbS8ifQ==
... (client has to send again something for AUTH command to terminate)
A0 NO [AUTHENTICATIONFAILED] AUTHENTICATE Invalid credentials

Thunderbirds logs:
2018-02-17 15:47:14.336000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4rev1 ID MOVE NAMESPACE XYMHIGHESTMODSEQ UIDPLUS LITERAL+ CHILDREN SASL-IR AUTH=PLAIN AUTH=XYMCOOKIEB64 AUTH=XOAUTH2 AUTH=OAUTHBEARER] IMAP4rev1 Hello
2018-02-17 15:47:14.338000 UTC - 7552[19d8eb00]: try to log in
2018-02-17 15:47:14.338000 UTC - 7552[19d8eb00]: IMAP auth: server caps 0x840007625, pref 0x1006, failed 0x0, avail caps 0x1004
2018-02-17 15:47:14.338000 UTC - 7552[19d8eb00]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
  LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
2018-02-17 15:47:14.338000 UTC - 7552[19d8eb00]: trying auth method 0x1000
2018-02-17 15:47:14.348000 UTC - 7552[19d8eb00]: got new password
2018-02-17 15:47:14.349000 UTC - 7552[19d8eb00]: IMAP: trying auth method 0x1000
2018-02-17 15:47:14.349000 UTC - 7552[19d8eb00]: PLAIN auth
2018-02-17 15:47:14.349000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 1 authenticate PLAIN
2018-02-17 15:47:14.436000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: + 
2018-02-17 15:47:14.436000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
2018-02-17 15:47:14.672000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: + eyJzdGF0dXMiOiJzZXJ2ZXJfZXJyb3IiLCJzY2hlbWUiOiJiYXNpYyIsInNjb3BlIjoiaHR0cHM6Ly9tYWlsLnlhaG9vLmNvbS8ifQ==
2018-02-17 15:47:14.673000 UTC - 7552[19d8eb00]: login succeeded
2018-02-17 15:47:14.678000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 2 namespace
2018-02-17 15:47:18.765000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 1 NO [AUTHENTICATIONFAILED] AUTHENTICATE Invalid credentials

As can be seen in logs, Thunderbird considers (even before receiving the NO response) that it is a success ("login succeeded") while it is not.
It then behaves as it would in an authenticated account and tries to:
* identify itself
2018-02-17 15:47:18.765000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 3 ID ("name" "Thunderbird" "version" "52.6.0")
2018-02-17 15:47:18.867000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: * ID ("remote-host" "..." "vendor" "Yahoo! Inc." "support-url" "http://help.yahoo.com/" "name" "Y!IMAP" "host" "sky700112.imap.mail.yahoo.com" "version" "1.1.11419")
2018-02-17 15:47:18.867000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 3 OK ID completed

* list folders
2018-02-17 15:47:18.868000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 4 list "" "*"
2018-02-17 15:47:22.956000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 4 BAD [CLIENTBUG] LIST Command is not valid in this state
2018-02-17 15:47:22.956000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 5 lsub "" "*"
2018-02-17 15:47:27.038000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 5 BAD [CLIENTBUG] LSUB Command is not valid in this state
2018-02-17 15:47:27.038000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 6 list "" "INBOX"
2018-02-17 15:47:31.120000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 6 BAD [CLIENTBUG] LIST Command is not valid in this state
2018-02-17 15:47:31.120000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 7 list "" "Trash"
2018-02-17 15:47:35.203000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 7 BAD [CLIENTBUG] LIST Command is not valid in this state

* create folders
2018-02-17 15:47:35.203000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 8 create "Trash"
2018-02-17 15:47:39.283000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 8 BAD [CLIENTBUG] CREATE Command is not valid in this state

* access INBOX (SELECT)
2018-02-17 15:47:39.284000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:SendData: 9 select "INBOX"
2018-02-17 15:47:43.366000 UTC - 7552[19d8eb00]: 19e4f800:imap.mail.yahoo.com:NA:CreateNewLineFromSocket: 9 BAD [CLIENTBUG] SELECT Command is not valid in this state



Expected results:

Thunderbird should properly handle the issue as an authentication failure and:
* report it as such; which e.g. triggers asking again the user for its login/password
* not consider the account as accessed (LIST, SELECT, CREATE are useless in this state)

Comment 1

[julien.coloos]

I think the issue is that Thunderbird does not properly implements the AUTHENTICATE mechanism where more than one continuation response can be sent from the server (https://tools.ietf.org/html/rfc3501#section-6.2.2).
In particular here the first one serves to let the client go ahead and send the authentication information (as such the server indicates it handles the AUTH method), and upon failure (on Yahoo at least) a second one serves to send some structured details(*) before failing the command.
As can be seen in the logs, upon receiving the second continuation response, thunderbirds considers the authentication successully done and tries to get the IMAP NAMESPACE ("2 namespace" is sent to the server). It then reads the actual authentication NO response and thinks it is for the just sent NAMESPACE command.


(*) The decoded base64 response is some JSON: {"status":"server_error","scheme":"basic","scope":"https://mail.yahoo.com/"}

Comment 2

[gene smith]

An issue very similar to this in Bug 1408610 was addressed and fixed about 4 months ago in this changeset:

https://hg.mozilla.org/comm-central/rev/83f249160f6c

It was targeted for v58 that is still in beta. I couldn't tell from the release notes if this is actually in beta 58 or 59, but I think it should be.

Reporter, I haven't read in detail all your posting yet. So does it seem like the change above will fix your issue?

Comment 3

[Jorg K (CEST = GMT+2)]

Available in TB 58 beta and TB 59 beta.

Comment 4

[Wayne Mery (:wsmwk)]

Please test the beta from  http://www.mozilla.org/en-US/thunderbird/channel/

Comment 5

[julien.coloos]

Indeed. I did not find this ticket when searching for past issues.
The last comments in the ticket and the patch do match the issue I encountered.

I quickly tested the beta version on an empty profile with a correct and invalid password. The fix works as expected and TB treats the authentication issue as such compared to what happens in v52.

Is a stable version 58/59 scheduled soon, or is there a chance to have the fix backported in branch 52 ?

Comment 6

[Jorg K (CEST = GMT+2)]

TB 60 ESR will be coming out in May 2018, but I can include bug 1408610 in TB 52.7.

Comment 7

[julien.coloos]

It could be useful.
As it happens, during a few hours the Yahoo server failed any authentication attempt (even with correct password). Since TB was configured to keep a copy of messages locally, after some time with this bug it considered my account empty (since it would find no folder) and deleted them. When I got access again it had to re-download everything from the server.