11.97 KB, text/html
169.58 KB, image/png
2.09 KB, patch
|Details | Diff | Splinter Review|
11.84 KB, text/html
6.15 MB, video/avi
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.
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
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?
This smells really related to the Zeus rate limiting that I have been bothered by for a few months.
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.
Also this would be ineffective for people that have visited a page and have bug_modal.js cached still.
(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.
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.
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.
> 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.
(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+
(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.
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.
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.
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.
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
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
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!
>> 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).
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?
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.