Closed Bug 1360842 (CVE-2017-7783) Opened 3 years ago Closed 3 years ago

DOS using long Username in URL scheme

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- fixed

People

(Reporter: cse, Assigned: Gijs)

References

()

Details

(Keywords: csectype-dos, sec-low, Whiteboard: [reporter-external] [web-bounty-form] [verif?][adv-main55+][post-critsmash-triage])

Attachments

(2 files, 1 obsolete file)

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:Password@mozilla.org
- 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...
Flags: sec-bounty?
You are reporting this for firefox rather than mozilla.org, yes?
(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
Group: websites-security → firefox-core-security
Component: Other → Security
Product: Websites → Firefox
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.
Flags: needinfo?(gijskruitbosch+bugs)
Assignee: nobody → gijskruitbosch+bugs
Group: firefox-core-security → core-security
Status: UNCONFIRMED → ASSIGNED
Component: Security → Networking: HTTP
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)
Product: Firefox → Core
Attached patch Patch v0.1 (obsolete) — Splinter Review
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...)
Attachment #8864460 - Flags: review?(mcmanus)
Attachment #8864460 - Flags: review?(mcmanus) → review?(valentin.gosu)
Group: core-security → network-core-security
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.
Attachment #8864460 - Flags: review?(valentin.gosu) → feedback+
Attached patch Patch v0.2Splinter Review
Thanks!

I wonder if we should update the nsGlobalWindow code to use the nsContentUtils method for its ellipsis character, too...
Attachment #8864460 - Attachment is obsolete: true
Attachment #8865022 - Flags: review?(valentin.gosu)
Attachment #8865022 - Flags: review?(valentin.gosu) → review+
https://hg.mozilla.org/mozilla-central/rev/8c22193abbf4
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Group: network-core-security → core-security-release
Should we assign a CVE?
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
Flags: sec-bounty? → sec-bounty-
(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.
Whiteboard: [reporter-external] [web-bounty-form] [verif?] → [reporter-external] [web-bounty-form] [verif?][adv-main55+]
Alias: CVE-2017-7783
The report is resolved, can you make it public?
(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.
Flags: qe-verify-
Whiteboard: [reporter-external] [web-bounty-form] [verif?][adv-main55+] → [reporter-external] [web-bounty-form] [verif?][adv-main55+][post-critsmash-triage]
(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.
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
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.