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

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Mario Gomes]

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

Comment 1

[Mario Gomes]

Attachment: poc.html

Comment 2

[Mario Gomes]

Attachment: screenshot.png

Comment 3

[Caglar Ulucenk [:cag]]

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.

Comment 4

[Julien Vehent]

Setting sec-low because blocked by CSP.

Comment 5

[Mario Gomes]

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?

Comment 6

[Dylan Hardison [:dylan] (he/him)]

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

Comment 7

[Dylan Hardison [:dylan] (he/him)]

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.

Comment 8

[Dylan Hardison [:dylan] (he/him)]

Also this would be ineffective for people that have visited a page and have bug_modal.js cached still.

Comment 9

[Mario Gomes]

(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.

Comment 10

[Dylan Hardison [:dylan] (he/him)]

(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.

Comment 11

[Dylan Hardison [:dylan] (he/him)]

Attachment: no-referrer.patch

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.

Comment 12

[Dylan Hardison [:dylan] (he/him)]

Safari seems to actually work -- but testing requires https.

Edge seems to truncate overly long Referer headers.

Comment 13

[Dylan Hardison [:dylan] (he/him)]

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. :-)

Comment 14

[Dylan Hardison [:dylan] (he/him)]

Attachment: no-referrer-v2.patch

Okay, it's just the order of the meta matters to Safari. So this patch seems to work in all supported browsers.

Comment 15

[April King [:April]]

> 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.

Comment 16

[Mario Gomes]

(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?

Comment 17

[April King [:April]]

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 18

[David Lawrence [:dkl]]

Comment on attachment 8945320 [details] [diff] [review]
no-referrer-v2.patch

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

r=dkl

Comment 21

[April King [:April]]

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.

Comment 22

[Mario Gomes]

(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.

Comment 23

[Mario Gomes]

Attachment: poc.html(AGAINST BUGZILLA.MOZILLA.ORG)

Comment 24

[Mario Gomes]

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.

Comment 25

[Mario Gomes]

Attachment: Video demonstrating how to reproduce this(29 seconds long).

Comment 26

[Dylan Hardison [:dylan] (he/him)]

it will not work after the patch is applied, anyway.

Comment 27

[Mario Gomes]

Is this eligible for a reward?

Comment 28

[Caglar Ulucenk [:cag]]

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.

Comment 29

[Mario Gomes]

Hey,

why is this taking this long to be fixed?

Comment 31

[Julien Vehent]

> 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.

Comment 32

[Mario Gomes]

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!

Comment 33

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

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.

Comment 34

[Mario Gomes]

>> 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).

Comment 35

[Mario Gomes]

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?

Comment 36

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

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

[April King [:April]]

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!