1739992 - Firefox 94 auto-fills spam-detection honeypot field on login.launchpad.net / login-lp.staging.ubuntu.com

Status: RESOLVED FIXED

(Toolkit :: Password Manager: Site Compatibility, defect, P2)

Description

[cjwatson]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

I went to staging.launchpad.net, selected "Log in / Register", and went through the login flow on login-lp.staging.ubuntu.com.

(I'm a launchpad.net developer. Note that this may not reproduce for all users, depending on form history. I found that I couldn't personally reproduce it on our production site, launchpad.net / login.launchpad.net, but we've had multiple reports from users of having this problem on production with Firefox 94: for instance, see https://bugs.launchpad.net/canonical-identity-provider/+bug/1950073 and https://answers.launchpad.net/canonical-identity-provider/+question/699317.)

Actual results:

At the last stage of logging in, Firefox POSTs to https://login-lp.staging.ubuntu.com/<token>/+decide, incorrectly auto-filling this form field with my email address:

<div style="display: none;">
<label>Leave this field blank to prove your humanity
<input type="text" name="openid.usernamesecret" value="" />
</label>
</div>

login-lp.staging.ubuntu.com (or login.launchpad.net for production) then detects that its automated-login honeypot has been triggered, and says "Bad bot, go away! Request aborted."

Expected results:

Firefox should not autofill the "display: none" openid.usernamesecret field on this form.

Comment 1

[cjwatson]

See also https://bugs.launchpad.net/canonical-identity-provider/+bug/1474841 for some history and another recent report.

Comment 2

[Pierre E.]

I tried running mozregression (with mozregression --bad 95 --good 93), but the problem happens only on profiles with form history, so I cannot reproduce this problem using mozregression.

The workaround is to:

• Make the hidden form visible using the Webdev tools
• Delete its content (since it's been populated with my e-mail address)
• Press the button to finish the login process

Comment 3

[Petruta Horea [:phorea]]

Attachment: bad request.png

I reproduced the issue while trying to confirm my newly created account while following the link from the validation e-mail. I requested several validation e-mails and the error was displayed each time after clicking the "I'm not a robot" check, so confirming.

I was able to validate the e-mail using Chrome.

However, with the same profile, I am able to login to https://login-lp.staging.ubuntu.com each time, with different Firefox versions under Win 10 and Ubuntu 20.04 Wayland, so I can't use mozregression to find the regressor.

@cjwatson, could you please install the gui version of mozregression and select the profile folder in Bisection step 2 (Firefox profiles are usually placed in Home -> .mozilla -> firefox) and search for the regression range? Thank you!

Comment 4

[cjwatson]

I used mozregression-gui to bisect from Firefox 93 to 94. It gave me https://phabricator.services.mozilla.com/D124538, but every revision I tested was bad and that change looks unrelated. Even Firefox 92 shows the same symptoms, despite the fact that I'm sure we saw a sudden uptick of users reporting this problem with Firefox 94. I think the badness must end up persisting in the profile. Indeed:

$ sqlite3 ~/.mozilla/firefox/9m1oaqd8.default/formhistory.sqlite
sqlite> select * from moz_formhistory where fieldname = 'openid.usernamesecret';
66932|openid.usernamesecret|[e-mail]|6|1636374405285000|1636375058627000|TF+nJfPvRnSXzXNS

But just deleting that row from that table doesn't make a difference. What does make a difference is removing this entry from logins.json:

{"id":330,"hostname":"https://login-lp.staging.ubuntu.com","httpRealm":null,"formSubmitURL":"https://login-lp.staging.ubuntu.com","usernameField":"email","passwordField":"password","encryptedUsername":"<redacted>","encryptedPassword":"<redacted>","guid":"{925b499c-e94a-46e2-8021-6a32a001ba92}","encType":1,"timeCreated":1535107395333,"timeLastUsed":1635240461611,"timePasswordChanged":1535107395333,"timesUsed":37}

I wondered why I wasn't seeing the same symptom on launchpad.net / login.launchpad.net, despite having very similarly-structured entries in logins.json for that. But in fact I have three logins saved there due to things like test users. So I tried this procedure:

• Make a backup of logins.json.
• Delete all but one entry for login.launchpad.net from logins.json (using https://github.com/glondu/nss-passwords to check that I'd got the manual edit right).
• Start Firefox 92 using mozregression-gui.
• Delete cookies for launchpad.net (since I was previously logged in).
• Go to https://launchpad.net/, log in, and follow prompts on login.launchpad.net.
• "Bad bot, go away!"

So definitely something to do with handling of saved logins, but so far I've had no luck with bisection. Any suggestions as to what to try next?

Comment 5

[Diogo Constantino]

Attachment: Screenshot of a failed attempt to login on launchpad.net

Comment 6

[Diogo Constantino]

I confirm this is also happening with me.

Comment 7

[Timea Cernea [:tbabos][inactive]]

First of all, big thanks to everyone in this thread that provided so much valuable information about this issue!
Second, I also managed to reproduce it on the latest Firefox Release 94 on MacOS and also found via mozregression that Bug 1708455 introduced this regression.
We indeed fill in the hidden field that was not supposed to be auto-filled. Attached recording of how the issue is reproducible and I also have a profile set up to easily reproduce this. Let me know if you need it to investigate this further.

Bug 1708455 introduced autofill support for username-only forms as well and was just recently enabled in Release 94, as per Comment 19.

Hey Dimi, could you please look into this when you have the time? Thanks!

Comment 8

[Timea Cernea [:tbabos][inactive]]

Attachment: Affected build - hidden field is autofilled

Comment 9

[Timea Cernea [:tbabos][inactive]]

Attachment: Good build

Comment 10

[Timea Cernea [:tbabos][inactive]]

Attachment: Reproduced

Comment 11

[Timea Cernea [:tbabos][inactive]]

Attachment: Steps to reproduce

Comment 12

[Timea Cernea [:tbabos][inactive]]

Note: to bypass this issue until it is fixed, you can switch the following preference to "false" via about:config:
signon.usernameOnlyForm.enabled

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 14

[Dimi Lee [:dimi]]

(In reply to Timea Cernea [:tbabos] from comment #7)

Hey Dimi, could you please look into this when you have the time? Thanks!

This is exactly the same issue as Bug 1724136, which we added a site recipe for host login.ubuntu.com.
For a short-term fix, I can add login-lp.staging.ubuntu.com, launchpad.net and login.launchpad.net to the recipe.
As for long-term, we will need to fix Bug 1247245.

Comment 15

[cjwatson]

launchpad.net isn't needed here (it delegates to login.launchpad.net for its login workflow). However, if you're making exceptions, all these four hosts should be treated the same way:

• login.ubuntu.com
• login.launchpad.net
• login.staging.ubuntu.com
• login-lp.staging.ubuntu.com

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1708455

Comment 17

[Dimi Lee [:dimi]]

(In reply to cjwatson from comment #15)

launchpad.net isn't needed here (it delegates to login.launchpad.net for its login workflow). However, if you're making exceptions, all these four hosts should be treated the same way:

Thank you for the information! I'll include all the hosts here.

Comment 18

[Dimi Lee [:dimi]]

Hi cjwatson, we have updated the change to the server, could you help check if this issue is fixed now? thanks!

Comment 19

[Pierre E.]

(In reply to Dimi Lee [:dimi] from comment #18)

Hi cjwatson, we have updated the change to the server, could you help check if this issue is fixed now? thanks!

I just tried with FF 94.0 (the same that was causing me troubles a few days ago) by connecting to a Launchpad page that requires 2FA, as well as by connecting to an internal page that uses login.ubuntu.com for identification. In both cases, I did not witness the original issue.

Comment 20

[cjwatson]

I've tried my previous reproduction steps with Firefox 94, and everything I ran into has been fixed now. Thanks for the quick action!

Comment 21

[Dimi Lee [:dimi]]

Pierre, cjwatson, thank you for testing!

Comment 22

[guiverc]

I'm still getting issues when I

• boot a jammy daily (canary build; 2021-11-16 yesterday & 2021-11-17 today) ISO
• install (subiquity) which has issue, so I try and report issue
• login to launchpad, then greeted with

"Bad Request \n\n Bad bot, go away! Request aborted."

Name Version Rev Tracking Publisher Notes
.. [redacted]
firefox 94.0.1-1 701 latest/stable/… mozilla* -

Comments and ISOs experiencing issues can be found on https://bugs.launchpad.net/canonical-identity-provider/+bug/1950073 (tracked on iso.qa.ubuntu.com)

I tried snap refresh to look for any updates; updates found for ubuntu-desktop-installer & core20 only.

Comment 23

[guiverc]

I experienced the issue again using

• Xubuntu jammy daily (2021-11-18)
• install failure (ubiquity) & tried to file bug
• login to launchpad & error.

Xubuntu uses the deb package (not snap)

firefox:
Installed: 94.0+build3-0ubuntu1

I note Leok had install failure using same daily ISO, but did NOT have issue with firefox login.

To get around issue; I opened new tag & attempted login; on 4th attempt I didn't get a bad bot error, then re-filed bug report.
Bad bot error appears inconsistent? 4th attempt with Xubuntu; it was 2nd or 3rd earlier today (timing?)

Comment 24

[Olivier Tilloy]

@guiverc, I suspect this is caused by running firefox 94.0.1 for the first time, with a fresh profile, which won't have the updates site recipes until they are fetched from Mozilla's servers.