Prevent bugzilla static assets from being blocked by overly long request URIs

RESOLVED FIXED

Status

()

RESOLVED FIXED
a year ago
10 months ago

People

(Reporter: netfuzzerr, Assigned: dylan)

Tracking

({sec-low, wsec-xss})

Development
sec-low, wsec-xss
Bug Flags:
sec-bounty -
sec-bounty-hof +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reporter-external] [web-bounty-form] [verif?], URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

a year ago
Hello,

https://www.mozilla.org/en-US/security/web-bug-bounty/ says XSS blocked by CSp are also interesting, as result of that, i'm reporting this bug again.

Steps to reproduce(tested on Chrome and Firefox, both with CSP DISABLED):
1. clean your browser cache.
2. open poc.html.
3. you'll be redirect to https://bugzilla-dev.allizom.org/show_bug.cgi?id=1155036.
4. click in the Javascript link in the first comment.
5. see the xss alert.

This vulnerability occurs because the page fails to load bug_modal.js, this file has the code responsable for validating the URL attribute. Using a enormous link I can force the page to not load bug_modal.js resulting in the csp blocked persistent xss.

cheers,
Mario
Flags: sec-bounty?
(Reporter)

Comment 1

a year ago
Posted file poc.html
(Reporter)

Comment 2

a year ago
Posted image screenshot.png
Hi Mario,

Thanks for reporting this. Interesting way to trigger failure of loading a site resource. I was able to verify this in Firefox with CSP explicitly disabled in the browser.

:dylan, are you also able to look into this? I am aware for this to be exploited CSP needs to be explicitly disabled (or the victim should use an older browser/IE 11 which does not understand CSP), however, it would be good to identify the root cause of this behaviour and possibly address it as a part of defence-in-depth principles.
Flags: needinfo?(dylan)
Setting sec-low because blocked by CSP.
Assignee: nobody → dylan
Group: websites-security → bugzilla-security
Status: UNCONFIRMED → ASSIGNED
Component: Other → General
Ever confirmed: true
Keywords: sec-low, wsec-xss
Product: Websites → bugzilla.mozilla.org
Version: unspecified → Development/Staging
(Reporter)

Comment 5

a year ago
Setting this as "sec-low" conflicts with https://www.mozilla.org/en-US/security/web-bug-bounty/ saying XSS(blocked by csp) is eligible for rewards, doesn't  it?
(Assignee)

Comment 6

a year ago
This smells really related to the Zeus rate limiting that I have been bothered by for a few months.
(Assignee)

Comment 7

a year ago
Okay, so after the misdirection this is the same adding a bunch of stuff to the URL so that the request is large enough to get blocked by the http. 

This is definitely low *also* because it results in an unstyled page some of the time. While the script does an admirable job trying to make the browser pre-load all the required assets, this will fail some percentage of the time due to cache pressure.

To defend against this I'm going to send a preload header for bug_model.js, and I'm going to make show_bug.cgi not return content when its content requests would be too large for the backend httpd.
Flags: needinfo?(dylan)
(Assignee)

Comment 8

a year ago
Also this would be ineffective for people that have visited a page and have bug_modal.js cached still.
(Reporter)

Comment 9

a year ago
(In reply to Dylan Hardison [:dylan] (he/him) from comment #8)
> Also this would be ineffective for people that have visited a page and have
> bug_modal.js cached still.

Exactly. That's why browser cache has to be cleaned up.

(In reply to Dylan Hardison [:dylan] (he/him) from comment #7)
> This is definitely low *also* because it results in an unstyled page some of
> the time.

Not true. My script loads the necessary js and css files and forces the browser to cache it before redirecting in order to prevent that. If victim has already visited the page and has bug_modal.js along with the other js/css files in cache, the page will be displayed normally. Either the attack works or not it would never show an unstyled page.
(In reply to Mario Gomes from comment #9)
> (In reply to Dylan Hardison [:dylan] (he/him) from comment #8)
> > Also this would be ineffective for people that have visited a page and have
> > bug_modal.js cached still.
> 
> Exactly. That's why browser cache has to be cleaned up.
> 
> (In reply to Dylan Hardison [:dylan] (he/him) from comment #7)
> > This is definitely low *also* because it results in an unstyled page some of
> > the time.
> 
> Not true. My script loads the necessary js and css files and forces the
> browser to cache it before redirecting in order to prevent that. If victim
> has already visited the page and has bug_modal.js along with the other
> js/css files in cache, the page will be displayed normally. Either the
> attack works or not it would never show an unstyled page.

That's not the behavior observed (and not just in this issue).
In general browsers don't always cache when you ask them to, or for as long as you'd want them to.
Posted patch no-referrer.patch (obsolete) — Splinter Review
First patch: 

In this patch, if the request_uri is over a certain size, we selectively turn off full (same-site) referrers.
This works in Firefox and Chrome, but not safari.

dkl: to trigger this, just visit any page and make the URL in the address bar > 8k. Make sure to shift-reload or clear cache.
Attachment #8945255 - Flags: review?(dkl)
(Assignee)

Updated

a year ago
Summary: persistent in bug attribute. → Prevent bugzilla static assets from being blocked by overly long request URIs
Safari seems to actually work -- but testing requires https.

Edge seems to truncate overly long Referer headers.
with Patch 1, it seems Firefox, Chrome, and Edge all honor the referrer policy header or the meta referrer.

Note it is important preserve full referers within the app as it is currently used for maintaining history actions on search results.

Until we can switch to a more reliable httpd (or until safari is fixed) safari will not be allowed to view any page that would cause overly large referer headers to be sent. This will be patch 2. :-)
Okay, it's just the order of the meta matters to Safari. So this patch seems to work in all supported browsers.
Attachment #8945255 - Attachment is obsolete: true
Attachment #8945255 - Flags: review?(dkl)
Attachment #8945320 - Flags: review?(dkl)
> Setting this as "sec-low" conflicts with https://www.mozilla.org/en-US/security/web-bug-bounty/ saying XSS(blocked by csp) is eligible for rewards, doesn't  it?

sec-low simply helps us prioritize bugs, it doesn't determine whether or not it's eligible for the bug bounty program.
(Reporter)

Comment 16

a year ago
(In reply to April King [:April] from comment #15)
> sec-low simply helps us prioritize bugs, it doesn't determine whether or not
> it's eligible for the bug bounty program.

Last time I checked only bugs rated as 'sec-moderate' and above were considered for reward, not sure if things changed lately, did it?
Yes, we removed that about a year ago when we revamped the web bug bounty program. Now payouts are explicitly listed and based upon website and class of bug.
Comment on attachment 8945320 [details] [diff] [review]
no-referrer-v2.patch

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

r=dkl
Attachment #8945320 - Flags: review?(dkl) → review+
I have tested this with CSP on bugzilla-dev.allizom.org, and while I can trigger a JavaScript popup (both with javascript: and data: URIs), I can only trigger it with the warning ahead of time where it says it:

This is considered an unsafe URL and could possibly be harmful.

Mario, are you able to get an XSS to trigger without that warning? With the warning, it's not really any different than a self-XSS.
(Reporter)

Comment 22

a year ago
(In reply to April King [:April] from comment #21)
> Mario, are you able to get an XSS to trigger without that warning? With the
> warning, it's not really any different than a self-XSS.

Before trying it you must clean your browser's cache otherwise it will load the js files it has stored and the attack will fail.
(Reporter)

Comment 24

a year ago
I have updated the poc to work against bmo.
Steps to reproduce:
1. Clean your BROWSER CACHE.
2. Visit https://bugzilla.mozilla.org/attachment.cgi?id=8948488
3. you will redirected back to this bug.
4. now click in the URL field.
5. see the xss alert.
it will not work after the patch is applied, anyway.
(Reporter)

Comment 27

a year ago
Is this eligible for a reward?
Bugzilla is among the eligible websites for bug bounty. I am pretty sure whether or not it warrants a reward / what kind of reward would be discussed in our weekly bug bounty committee meeting.
(Reporter)

Comment 29

a year ago
Hey,

why is this taking this long to be fixed?
> why is this taking this long to be fixed?

We appreciate your report and participation in our bug bounty program, but the prioritization of fixes is something we handle internally, and depends on the risk level and other priorities the team has to consider. This is a sec-low, so we won't rush getting a fix out. Asking about updates unnecessarily increases stress without helping us go any faster.
(Assignee)

Updated

a year ago
Summary: Prevent bugzilla static assets from being blocked by overly long request URIs → Prevent bugzilla static assets from being blocked by overly long request URIs
(Assignee)

Updated

a year ago
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
(Assignee)

Updated

a year ago
Group: bugzilla-security
Flags: sec-bounty?
Flags: sec-bounty-hof+
Flags: sec-bounty-
(Reporter)

Comment 32

a year ago
https://www.mozilla.org/en-US/security/web-bug-bounty/ says CSP XSS are eligible for bounty. Why this didn't qualify? I don't understand why create a bounty table and do not follow it. Please stop lying to researchers!
To summarize the proposed exploit scenario...

1.) User disables CSP in their browser (it's enabled by default)
2.) User must clear their browsers cache
3.) User visits bug A and clicks an html attachment, which redirects them to bug B
4.) User clicks a URL in bug B, which points to javascript:alert(document.domain);
5.) User is presented a warning screen that says...

"This is considered an unsafe URL and could possibly be harmful. The full URL is:

javascript:alert(document.domain);

Continue?"

6.) User ignores the security warning and clicks "ok" and executes the JS in URL field

Based on the discussion by the bounty team today, we don't believe this is a plausible exploit scenario that would affect a real user without being coached through it and intentionally ignoring browser security warnings with warn the user about it's unsafeness.  We do state that we will and often do pay for XSS bugs that are mitigated by CSP, but the other factors (like plausibility of a user following those steps and ignoring security warnings) played a role in our decision to award an HoF for this report.
(Reporter)

Comment 34

a year ago
>> 5.) User is presented a warning screen that says...

No warning would be displayed if this exploit worked. That's the point of this vulnerability, use a giant url that would force a error while trying to load the js responsabible for display the warning. 

Please, understand that NO WARNING WOULD BE DISPLAYED(because the browser wouldn't load the js file that contains warnning).
(Reporter)

Comment 35

a year ago
My exploit scenario would be:
1. Victim visits poc.html after it is redirected /show_bug.cgi?id=bugid&<giant-string>
2. victim clicks on the URL field
3. XSS CODE GETS EXECUTED. 
Note: In order this to work, victim mustn't have visited(cached) any show_bug.cgi url recently, that's why it is necessary to clean browser's cache.

Of course, this would only work if victim has CSP disabled.

Did you at least try the poc before deciding? Did you see the video that I posted where it's shown how the exploitation works?
Thanks for the clarification, I did not witness the working PoC myself, I'm working from the information in the bug history and with those who triaged the vulnerability.  I sat down with :dylan and :april individually and we walked through possible threat scenarios to come up with the following reproduction steps (pre-bugfix) to make sure we're all on the same page in terms of behavior and probable user flows and their caveats.

1.) User disables CSP in their browser (it's enabled by default)
2.) User has an empty browser cache for https://bugzilla.mozilla.org (it's statistically improbable to be logged in to BMO without having seen a bug, making this extremely unlikely or require phishing to elicit to user cache clearing action)
3.) Attacker phishes user to visit a specific attachment URL, which causes a load of a really really long URI string (~8124K chars)
4.) When page loads it will cause external JS resources to fail (or not load), one of which include the JS that presents the user warning.
5.) User is then convinced to click the URL link within the bug with partially failed JS loads that point to "javascript:.." or some "data://..." equivalent and this is executed in the browser without a warning.

Even with this reduced flow, this is an implausible scenario because we need all of the following to be true for this to be a viable vector.  If we consider that same context, less the CSP requirement, it is still improbable to exploit or affect actual users using this.

- We're in a CSP-disabled scenario
- We're in a state where a user has a fully cleared BMO cache (this is considered something that would almost never happen in normal browsing/BMO behavior as any user in BMO will likely have seen one bug in the past year, and would necessitate some form of phishing otherwise)
- We're expecting additional user actions after the initial load, including the clicking of a dodgy URL parameter which contains data://... or javascript:... content (this is not something that happens automatically, and requires a curious user or user phishing activities to visit the URL link in the bug).

Functionally, given these requirements and their likelihood of lining up in a real-world scenario, this manifests as a self-xss equivalent or phishing scenario, which we explicitly exclude from the program eligibility in https://www.mozilla.org/en-US/security/web-bug-bounty/#exclusions.

All that said, we really appreciate your submission here and the creativity you demonstrated in your POC and that is why we decided to list you on our hall of fame.

Comment 37

10 months ago
Mario, can I ask how you would like to be credited on our Hall of Fame? I need the name you'd like to be credited with, as well as a URL to link to, if you'd like us to do that.

Thanks!
You need to log in before you can comment on or make changes to this bug.