Closed Bug 1571003 Opened 5 years ago Closed 4 years ago

Basic auth confirmation prompt spam / DOS

Categories

(Firefox :: Security, defect, P2)

70 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 72
Tracking Status
firefox70 + wontfix
firefox71 + verified
firefox72 + verified

People

(Reporter: pbz, Assigned: pbz)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-dos)

Attachments

(2 files)

Basic auth confirmation prompts can be abused for spamming users and stealing focus from the main window.

The prompts are created here:
https://searchfox.org/mozilla-central/rev/29cce9a2684ef64c4f1f996087da8b7545d31f65/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#1429

There does not seem to be any rate limiting, so this can also be used for DoS.

PoC: https://eviltrap.site/trap/confirm-auth-prompt-spam/
Source: https://github.com/Trikolon/evil-traps/blob/a3026929ebdf57aa3942490f58cd758d4f2d746d/src/traps/confirm-auth-prompt-spam/index.js#L6

I've attached a screenshot of the "Superfluous-Auth" confirmation prompt.

Priority: -- → P2
Keywords: csectype-dos
Summary: Basic auth confirmation prompt spam → Basic auth confirmation prompt spam / DOS
Assignee: nobody → pbz
Status: NEW → ASSIGNED

[Tracking Requested - why for this release]:
To add this to the RM radar

Tracking to keep an eye on this if we have a 70.0.2 release.

See Also: → 613785, 1281434, 1029815

There's also a similar AutomaticAuth prompt. These were implemented in 2004 (bug 232567) when many phishing attacks came through text links in mail or chat apps (AIM!). Spoofing users via the source link was popular: people looked more closely at what they were clicking on than they were likely to double-check the URL bar to make sure that's where they ended up. Potential victims knew spoofing via HTML was easy -- the link didn't have to look like a URL at all -- but tended to trust text more.

This also predated SafeBrowsing phishing protection by 5 years or so. Attacks are different now, and we have other defenses.

Pretty sure we can rip these out, but if we want to be more conservative we could pref them off and add telemetry to count how many times we see it being used in the wild. Between the two prompts there appear to be three cases.

SuperfluousAuth is used in two places:

  • the site does not use Auth (always suspicious)
  • the site uses auth (returns 401/407) but auth fails (might be a legit error, might be a phish trying to avoid the first case)

AutomaticAuth is a warning for the "normal" case of a URL with userinfo. Maybe it's legit, or maybe the phisher implemented auth to avoid the SuperfluousAuth warning.

We implemented these rather than follow IE's lead and simply reject any attempt to load a URL with userinfo. If telemetry shows a low incidence of the legit case maybe we can just follow suit at long last. But this bug should not be about that. Telemetry yes, but otherwise just solve the prompt DOS issue. We can revisit bug 479038 if we want to disable these entirely.

Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/01b72766ae26
Added pref to disable warning prompts for SuperfluousAuth and AutomaticAuth. r=Gijs
Blocks: 1594613
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72

Is there anything we can do here to verify? Or just let it bake in nightly a bit before trying uplift?

Flags: needinfo?(pbz)

Comment on attachment 9106867 [details]
Bug 1571003 - Added pref to disable warning prompts for SuperfluousAuth and AutomaticAuth. r=gijs

Beta/Release Uplift Approval Request

  • User impact if declined: DoS causing degraded browser performance and possibly OS instability. Prompts steal focus and make it difficult to close the website or browser. We've observed this being abused in the wild for phishing.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Confirmation prompts listed below should not show when opening the sites in default configuration.

AutomaticAuth shows when opening something like "http://user:password@jigsaw.w3.org/HTTP/Basic/" (directly shows login prompt when disabled)
SuperfluosAuth shows for something like "http://facebook.com@example.com". (no prompt when disabled)

  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Medium risk, because with the anti spoofing dialogs disabled we might open a new attack vector. We will watch this closely and introduce telemetry (Bug 1594613) to see how widely userinfo in the URI is (ab)used. See comment by :dveditz for a more in depth explanation.
  • String changes made/needed:
Flags: needinfo?(pbz)
Attachment #9106867 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

This issue is Verified as Fixed in our latest Nightly build 72.0a1 (2019-11-08) on Windows 10, Mac OsX 10.14 and Ubuntu 16.04.

Comment on attachment 9106867 [details]
Bug 1571003 - Added pref to disable warning prompts for SuperfluousAuth and AutomaticAuth. r=gijs

Let's take the uplift to beta now that QA has verified it in Nightly, uplift approved for 71.0 beta 9, thanks.

Attachment #9106867 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Hi, This issue is Verified as fixed in our latest Beta build 71.0b9 on Windows 10, Mac Osx 10.14 and Ubuntu 16.04.

Since 71 is going to ship in 2 weeks and we don't have a dot release planned, wontfix for 70 at this point.

Based on comment 14 and given the fact that the issue is already verified in fx71 and fx72, I will change the status accordingly.
Thanks.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Blocks: 1629808
You need to log in before you can comment on or make changes to this bug.