791594 - 401 password prompt spoofing thing

Status: RESOLVED FIXED

(Firefox :: Security, defect, P2)

Description

[Michal Zalewski]

Demo: http://lcamtuf.coredump.cx/authspoof/

You show a window-modal HTTP auth prompt visually tied to a particular tab before updating the address bar. This can have bad consequences when somebody navigates a trustworthy window to a malicious location. This seems rather undesirable.

Possible fix: update the address bar and hide the original document before showing the prompt?

Comment 1

[13hu]

seems to be blocked as popup in modern FF (71.0)
no longer issue ?

Comment 2

[bhargavdesai36]

I've checked in developer channel of Firefox, but it is opening google.com and after 3 second it is asking popup for with username and password for some website.

Can you please elaborate what is the exact issue over here?

Comment 3

[yan]

The issue is that the auth popup belongs to the attacker's tab, but it is being shown in the context of the current tab (google.com). The risk is that a user thinks that google.com is asking for credentials and enters their google password in the attacker-controlled popup. I verified this in Firefox Stable, desktop and iOS latest.

Comment 4

[Daniel Veditz [:dveditz]]

In case Michał's server ever goes away here is the testcase:

<input type=submit value="Click me" onclick="dostuff()">
<script>
  var w;

  function dostuff() {
    w = window.open('https://www.google.com', 'g');
    setTimeout(step2, 3000);
  }

  function step2() {
    w = window.open('http://199.58.85.40/a/', 'g');
  }
</script>

I'm not sure what good options we have with synchronous auth prompts, but ideally if we're navigating the top window and get a 401 we should blank the content window before showing the prompt. Clearing the addressbar isn't good enough -- if people knew they were on a particular site and the content stays the same they aren't likely to double-check the address bar.

Johann: please make sure this bug gets slotted into the right auth-prompt dependency tree and work plan

I'll clone bugs for mobile: if we're lucky Fennec/Fenix might Just Work if we fix this in Desktop but iOS certainly won't.

Comment 5

[Johann Hofmann [:johannh]]

Paul, this will be solved by making the auth prompt tab modal as part of bug 616843, right?

Comment 6

[Johann Hofmann [:johannh]]

So that would mean bug 613785...

Comment 7

[Johann Hofmann [:johannh]]

P1 obviously, really bad we had this for such a long time and I hope Paul's work will rid us of these issues once and for all...

Comment 8

[Daniel Veditz [:dveditz]]

I don't know if it will. The problem is that the content is already in the tab that's going to get the tab modal prompt, and normally we don't start to replace the page content until after we get the replacement data. We will have to do something special to explicitly blank the content when a 401 response requires us to prompting the user. The modal-ness isn't the problem in this case.

Comment 9

[Johann Hofmann [:johannh]]

We can try it out soon, but I think that associating the prompts with a browsingContext instead of just the window will do the trick. IIRC this issue was a case we specifically considered when making the new prompts, though I don't think we wrote a test for it. We should do that in this bug.

Comment 10

[Johann Hofmann [:johannh]]

Ok, sorry, looking at this again I misunderstood the bug. I thought that the issue was with navigating your own tab to a site that triggers basic auth and thus causing the window modal prompt to be overlaid on say, google.com. But the attacker is navigating the other tab. I'm not sure if Paul's patch will solve this now, to be honest. It will definitely give us a big advantage in solving this since we can continue drawing the browser Chrome etc., but there might be additional work needed.

In addition to blanking out the content area we will definitely have to set the URL bar to display the new top level URL.

Paul, can you take a look and see what happens in this scenario when the auth prompt is tab modal?

Thanks!

Comment 11

[Emma Zühlcke [:emz]]

Hi, sorry for the delayed reply!
I've tested it with a tab modal prompt. I'm simply switching the auth prompt call in LoginManagerAuthPrompter to tab modal:

diff --git a/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm b/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm
--- a/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm
+++ b/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm
@@ -744,8 +744,9 @@ LoginManagerAuthPrompter.prototype = {
           this._browser
         );
       }
-      ok = Services.prompt.promptAuth(
-        this._chromeWindow,
+      ok = Services.prompt.promptAuthBC(
+        this._browser.browsingContext,
+        Services.prompt.MODAL_TYPE_TAB,
         aChannel,
         aLevel,
         aAuthInfo,

However, even though its targeting the correct browser, it will show the prompt before updating the page / URL bar. The problem persists.

I've added the PoC here as well: https://eviltrap.site/trap/http-auth-prompt-spoof/

Comment 12

[Johann Hofmann [:johannh]]

Thanks! We should probably look at this sooner rather than later. Looking at the behavior in Chrome it seems like they update the URL bar to show the URL that's being loaded as well as blanking out the content area (and unloading the previous document).

I think that these are probably good ideas, unloading should be fine since even in the cancellation case we're going to render the contents that came with the initial 401 response and not the previous page.

Dragana/Smaug, do you have any thoughts on this from Necko/Docshell side? What would be required on your end for us to get to this state where the old document is unloaded and we can display something in the url bar before showing the basic auth prompt?

Thanks!

Comment 13

[Dragana Damjanovic [:dragana]]

I do not know when the old document is unloaded, is it when it DocShell gets OnStartRequest?

The thing with 401 is that only necko see it, it is a response in between and it is handle by necko the listener og a necko channel do not see it except the prompt is canceled. I will wait for imput from Smaug and than we can figure out how to propagate 401

Comment 14

[Chris Peterson [:cpeterson]]

Attachment: image.png

We are showing the tab-modal prompt during a navigation before the previous page has been unloaded.

In the demo https://eviltrap.site/trap/http-auth-prompt-spoof/, the address bar still shows example.com, even though the prompt says "eviltrap.site. This site is asking you to sign in."

Some UX options:

1. Blur example.com in the address bar. We can't show eviltrap.site in the address bar because the page is still showing example.com content.
2. Obscure example.com's page content. We already dim the page content, so obscuring it should be easy to implement.

Comment 15

[Emma Zühlcke [:emz]]

I'll take a look, but I can't commit to a specific timeline as of now.
If feasible I'm in favor of both updating the URL-bar and blanking the content area. Might need some band-aid fix in the frontend, if we can't mess with the navigation state.

Comment 16

[Emma Zühlcke [:emz]]

Hannah is looking into this.

Comment 18

[Hannah Peuckmann]

Attachment: WIP: Bug 791594 - Add nsIAuthPrompt2 security level, realm and auth flags to nsILoadInfo.

Comment 19

[Hannah Peuckmann]

Attachment: WIP: Bug 791594 - Add interstitial page that prompts for user credentials.

Depends on D160945

Comment 20

[Hannah Peuckmann]

Attachment: WIP: Bug 791594 - expose nsIAuthInformation to JS.

Depends on D160945

Comment 21

[Hannah Peuckmann]

Attachment: Bug 791594 - Gray out content behind cross origin auth requests. r=pbz!

Comment 22

[Hannah Peuckmann]

Attachment: Bug 791594 - Set URL bar state while prompt is open. r=pbz!

Depends on D164440

Comment 23

[Hannah Peuckmann]

Attachment: Bug 791594 - Set tab title state while auth prompt is open. r=pbz!

Depends on D164441

Comment 24

[Hannah Peuckmann]

Attachment: Bug 791594 - Hide authPromptSpoofing protection behind a pref. r=pbz!

Depends on D164442

Comment 25

[Emma Zühlcke [:emz]]

Thanks for the great work on this, Hannah!
I've noticed that the current patches for the URLBar don't update the identity section yet - we still show the shield and the lock for the old site, which is confusing. Do you think we could show the fallback state, the (i) instead? Ideally we'd show the connection info from the auth request, but that might be difficult to pass to the frontend, so just a fallback state work for me. Should we file a follow-up bug for that?

Comment 26

[Hannah Peuckmann]

Good idea, I think we should to that. Bug is filed.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/63d1f8a23fb4
Gray out content behind cross origin auth requests. r=pbz,Gijs,mconley
https://hg.mozilla.org/integration/autoland/rev/1bf8d8a60bb8
Set URL bar state while prompt is open. r=pbz,Gijs,adw
https://hg.mozilla.org/integration/autoland/rev/4ea502fb2357
Set tab title state while auth prompt is open. r=pbz,mconley,Gijs
https://hg.mozilla.org/integration/autoland/rev/e1d5f292fb83
Hide authPromptSpoofing protection behind a pref. r=pbz

Comment 28

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/63d1f8a23fb4
https://hg.mozilla.org/mozilla-central/rev/1bf8d8a60bb8
https://hg.mozilla.org/mozilla-central/rev/4ea502fb2357
https://hg.mozilla.org/mozilla-central/rev/e1d5f292fb83

Comment 29

[Hannah Peuckmann]

Looking at our telemetry, in about 60% of the cases that we receive a 401, it is due to a top-level cross-domain load. This is the case that is covered by the patch, so that is good.
The case that is not covered is the 401 from a cross-domain sub-resource, which seems to be around 5%, so it might be not that severe/urgent that we are not covering this case.
(Same-domain top-level load is at 17% and same-domain sub-resource requests are at 19%)