1360842 - (CVE-2017-7783) DOS using long Username in URL scheme

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Amit Sangra]

Attachment: In the scheme: http://UserName:[e-mail] → By submitting a very long value for UserName, DOS is performed.

User Agent:
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Description:
- To send username and password with a URL, we use this scheme: http://UserName:[e-mail]
- Opon visiting URL's of this scheme a prompt box is displayed confirming the login.
- The prompt box displays a message containing the username (From the URL).
- By supplying a very long value for the username we can make the prompt box crash. (Not a browser crash)
- This crash will cause DOS for the victim, and his browser will get locked out.

Note: I am able to crash with 10k characters long username.

Proof of Concept:
I can always reproduce by following these steps:

1. Start Firefox by clicking on the desktop icon
2. Press Cmd+N (or Ctrl+N for Windows users) to open a new browser window
3. Host the "Crash.php" file on your webserver. (Available as an attachment)
4. Paste http://<Your WebServer Address>/Crash.php in the address bar and press Enter
5. You browser will get locked out(DOS).

Proof of Concept URL: http://poc.rf.gd/crash.php

Expected results: The prompt box displays correctly.
Actual results: The prompt box crashes due to which DOS attack is performed on the victim.

Impact:
An attacker can create a webpage having some content and exploit.
Now once a victim visits this webpage, his browser gets locked out and he is forcibly made to view attacker supplied content.

Recommended Fix:
In the prompt box message, long usernames should be reconfigured to partially display such as:-

UserName: ThisIsALongUserName
Partial Value: ThisIsALongUse...

Comment 1

[Jeff Bryner [:jeff] (use NEEDINFO 😉)]

You are reporting this for firefox rather than mozilla.org, yes?

Comment 2

[Amit Sangra]

(In reply to Jeff Bryner [:jeff]  (use NEEDINFO) from comment #1)
> You are reporting this for firefox rather than mozilla.org, yes?

Yes, The issue is in Firefox Web Browser.
Regards

Comment 3

[:Gijs (he/him)]

This should be a straightforward fix, I'll try to find time later this week to put something up. Per https://wiki.mozilla.org/Security_Severity_Ratings this is a DoS-style attack which is sec-low.

Comment 4

[:Gijs (he/him)]

Attachment: Patch v0.1

I picked rather arbitrary cutoff points, given that this is mostly a spoofing protection, showing the entire values for host/username seems unnecessary.

Please carefully check my c++ string fu (ie is there a risk of chopping up valid ucs2 here, causing other problems?) and if the use of the localized ellipsis thing is actually correct. (It returns nsDependentString. I think passing that directly into Append() or Insert() is fine, but I am not a mozilla-c++-native-speaker - when I said I'd look into this, I though this would just need some XUL cropping, but that assumption turned out to be a mistake...)

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 8864460 [details] [diff] [review]
Patch v0.1

Review of attachment 8864460 [details] [diff] [review]:
-----------------------------------------------------------------

Apart from this, the patch looks good.

::: netwerk/protocol/http/nsHttpChannelAuthProvider.cpp
@@ +1547,5 @@
>  
>      NS_ConvertUTF8toUTF16 ucsHost(host), ucsUser(user);
> +
> +    if (ucsUser.Length() > MAX_DISPLAYED_USER_LENGTH) {
> +      ucsUser.Truncate(MAX_DISPLAYED_USER_LENGTH);

Indeed, we may need to cut out unpaired surrogates similar to:
http://searchfox.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#11780

@@ +1553,5 @@
> +    }
> +
> +    auto hostLen = ucsHost.Length();
> +    if (hostLen > MAX_DISPLAYED_HOST_LENGTH) {
> +      ucsHost.Cut(0, hostLen - MAX_DISPLAYED_HOST_LENGTH);

Same here.

Comment 6

[:Gijs (he/him)]

Attachment: Patch v0.2

Thanks!

I wonder if we should update the nsGlobalWindow code to use the nsContentUtils method for its ellipsis character, too...

Comment 7

[:Gijs (he/him)]

Landed this yesterday:

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/8c22193abbf4d51e8d29071dece384613a1b50b6

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8c22193abbf4

Comment 9

[Amit Sangra]

Should we assign a CVE?

Comment 10

[Daniel Veditz [:dveditz]]

FWIW I don't see a crash on Mac, just hangs up the browser for a second or so but then does show the confirmation box. Is this only a problem on 32-bit windows builds?

In any case, denial of service bugs are out of scope for the bug bounty program

Comment 11

[Amit Sangra]

(In reply to Daniel Veditz [:dveditz] from comment #10)
> FWIW I don't see a crash on Mac, just hangs up the browser for a second or
> so but then does show the confirmation box. Is this only a problem on 32-bit
> windows builds?
I could not test that on Mac but Firefox ESR 45.3.0 for Linux is also producing the crash. Seems like the problem is not limited to 32-bit Windows builds.
> In any case, denial of service bugs are out of scope for the bug bounty
> program
Yes, I am aware of that.

Comment 12

[Amit Sangra]

The report is resolved, can you make it public?

Comment 13

[Al Billings [:abillings - ex-MoCo]]

(In reply to Amit Sangra from comment #12)
> The report is resolved, can you make it public?

The issue is fixed in code. It hasn't shipped. It is part of Firefox 55 which doesn't ship for another week and a half. We generally don't open bugs fixed in a release until several weeks after we ship the release containing the fix.

Comment 14

[Amit Sangra]

(In reply to Al Billings [:abillings] from comment #13)
> (In reply to Amit Sangra from comment #12)
> > The report is resolved, can you make it public?
> 
> The issue is fixed in code. It hasn't shipped. It is part of Firefox 55
> which doesn't ship for another week and a half. We generally don't open bugs
> fixed in a release until several weeks after we ship the release containing
> the fix.

Ah I see, thanks for the information.

Comment 15

[Amit Sangra]

So, Firefox 55 is released and advisory for the issue has also been published.
https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#﷒0﷓