1683536 - (CVE-2021-23972) Bypassing http auth spoofing warning prompt when there's a cached redirect

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[Vijay Tikudave]

As firefox browser nightly have open redirect prevention whereby the warning prompt will be shown to user in case of malicious attempt of making redirect with help of "@" eg. if you open [e-mail]

It will show warning prompt to prevent any spoofing.

However this could be bypass with emoji.

eg. if user click on below url , it won't be prompted for redirect warning & adversary could use the bug to exploit issue.

https://www.facebook.com@☺️.com

it will redirect to adversary page without any redirect prompt

Comment 1

[:Gijs (he/him)]

This appears to work correctly on desktop nightly (though you get a certificate warning first with the https link from comment #0 that you need to click through before you get the other warning, if you modify the link to http:// then you get the warning immediately). Based on the original summary, I assume the intent was to report an issue with Fenix / Firefox for Android.

Comment 2

[Vijay Tikudave]

Yes, It is intended for Firefox android Fenix. is it accepted yet for progress?

Comment 3

[:Gijs (he/him)]

(In reply to Vijay Tikudave from comment #2)

Yes, It is intended for Firefox android Fenix. is it accepted yet for progress?

Most folks here are on break for the end of year, so it may be until January until someone responds. Any updates will appear on this bug.

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

Amedyne is there someone who you would recommend to look at this?

Comment 5

[Daniel Veditz [:dveditz]]

I got the warning the first time I tried this, but not after that. I see a similar behavior on Desktop: once the redirect from xn--74h.com to frueh.net is cached I no longer get the phishing warning. When I try the testcase with DevTools open (which disables the cache by default) I always get the warning, but with normal caching I don't.

This doesn't seem to have anything to do with the emoji, but with whether there is a redirect and whether that redirect is cached. You can reproduce this behavior with non-emoji domains like:
https://[e-mail]/
http://[e-mail]/

The fact that the redirect is cached means the user has been there before, but that doesn't negate this as an attack. For example in the CNN case above it's quite likely that if the user has gone to CNN at all they probably just typed it in to the addressbar without the 'www' and thus would have the redirect cached. Of course CNN isn't a phishing site, but maybe an attacker could load the phishing site in a hidden iframe to prime the redirect first, and then show the phishing link to the user.

Since this warning is generated in Necko (other than the display) common behavior makes sense, and this should be moved to Networking.

Comment 6

[Amedyne Moya [:amoya]]

Networking scope.

Comment 7

[Kershaw Chang [:kershaw]]

Apparently, nsHttpChannelAuthProvider::CheckForSuperfluousAuth is only called when the http response is from network. To fix this bug, we need to also call nsHttpChannelAuthProvider::CheckForSuperfluousAuth for cache path.

Comment 8

[Kershaw Chang [:kershaw]]

Attachment: Bug 1683536 - Show auth spoofing warning prompt for cached response

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/3d26a1f3b809522af0152918341a4b5ff924e4bb

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/3d26a1f3b809522af0152918341a4b5ff924e4bb
https://hg.mozilla.org/mozilla-central/rev/3d26a1f3b809

Comment 11

[Vijay Tikudave]

Hi,

is it eligible for bounty?

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

The sec-bounty flag has been set on this bug. It will be reviewed when the security group meets.

Comment 13

[Ciprian Georgiu, Desktop QA]

I've managed to confirm this fix on macOS 10.14, Ubuntu 18.04 x64 and Windows 10 x64, by following this steps:

1. Open http://[e-mail]
2. Expect to see the warning prompt
3. Open http://[e-mail] again. This time the response is from the cache.
4. The warning prompt should be shown again.

I've tested the bug on Beta 86.0b5. Thanks Kershaw, for helping me to verify this.

Comment 14

[Vijay Tikudave]

Hi,

is it eligible for CVE-ID alias?

Comment 15

[Tom Ritter [:tjr]]

Attachment: advisory.txt