Closed
Bug 1171758
Opened 9 years ago
Closed 9 years ago
Persistent xss is possible on Firefox
Categories
(bugzilla.mozilla.org :: General, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: netfuzzerr, Assigned: glob)
References
()
Details
(Keywords: sec-moderate)
Attachments
(2 files)
133.60 KB,
image/png
|
Details | |
2.30 KB,
patch
|
dkl
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 Steps to reproduce: Hi, It is possible to bypass the dialog alert when you set the URL param to javascript url then causing xss. THIS WORKS ONLY IN FIREFOX. Reproduce(FIREFOX ONLY): 1. First go to https://bugzilla-dev.allizom.org/attachment.cgi?id=8591389&action=edit using FIREFOX 2. Now a few pop-ups will show up, check the box "Prevent this page from creating dialogs" and click in "Ok". 3. after that, the frame will be redirected to https://bugzilla-dev.allizom.org/show_bug.cgi?id=1120074 4. now scroll down a little bit, and click in the "URL" field inside the iframe. 5. see the xss alert Let me know if you understand this vulnerability. To reproduce it I used the firefox dialogs boxes blocker, and a iframe pointing to the bug that has a URL with a javascript link causing the xss. Cheers, Mario
Reporter | ||
Comment 1•9 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Updated•9 years ago
|
OS: FreeBSD → Unspecified
Comment 2•9 years ago
|
||
I can reproduce the steps in comment 0 when using the standard Bugzilla UI (i.e.not glob's new one) and when logged in (because otherwise the URL is not autolinkified). Here's the potentially problematic code, on BMO only, in edit.html.tmpl: [% IF NOT is_safe_url(bug.bug_file_loc) %] onclick="return confirm( 'This is considered an unsafe URL and could possibly be harmful. ' + 'The full URL is:\n\n[% bug.bug_file_loc FILTER js FILTER html %]\n\n' + 'Continue?')" [% END %]> If Firefox has suppressed popups, confirm() dies or throws an exception or something, and the onclick handler ends, and the click is processed. The STR seem pretty involved to me, and seem to require multiple levels of framing, so I wonder quite how much of an issue this is? Gerv
Updated•9 years ago
|
Flags: sec-bounty?
Reporter | ||
Comment 3•9 years ago
|
||
Isn't anyone going to work in this issue ? Has it been confirmed ?
Comment 4•9 years ago
|
||
I think this is probably WONTFIX due to the incredible complexity of getting the POC to work, and the multiple user steps that are required. If we don't WONTFIX it, then we need to figure out whether we can detect if popups are suppressed in advance, or detect that a popup has failed to be shown, and handle that situation. NI dveditz: thoughts? Gerv
Flags: needinfo?(dveditz)
Reporter | ||
Comment 5•9 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #4) > I think this is probably WONTFIX due to the incredible complexity of getting > the POC to work, and the multiple user steps that are required. What complexity ? All what you gotta do is block those alert and click in the link inside the iframe that's all.
Comment 6•9 years ago
|
||
Right - that involves multiple user actions. Firstly, they have to visit the attack attachment. Then, they have to decide to block the alerts. Then, they have to choose to click the dodgy-looking URL inside the <iframe>. This is hardly drive-by. Gerv
Reporter | ||
Comment 7•9 years ago
|
||
> If we don't WONTFIX it, then we need to figure out whether we can detect if
> popups are suppressed in advance, or detect that a popup has failed to be
> shown, and handle that situation.
In order to fix this you must use 'try' and 'catch' handlers:
======
try{
confirm_go_on_in_dangerous_url();
}
catch(e){ // alert won't show up then a exception will be thrown
return false; // returning false browser won't move on to the 'javascript' url.
}
=====
See it isn't that hard :)
Reporter | ||
Comment 8•9 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #6) > Right - that involves multiple user actions. Firstly, they have to visit the > attack attachment. Then, they have to decide to block the alerts. Then, they > have to choose to click the dodgy-looking URL inside the <iframe>. This is > hardly drive-by. You made it look hard :/ First, when dozens javascript dialogs come up victim will certainly block them. Haven't never heard about 'clickjacking' ? Using clickjacking makes it easy to put a attractive/cute image/button over the javascript url. Making it not that much hard to exploit
thanks for this report mario, you never cease to bring interesting ways to exploit systems :) this patch treats a confirm exception as a failure, as suggested by mario.
Attachment #8624218 -
Flags: review?(dkl)
Comment 10•9 years ago
|
||
Comment on attachment 8624218 [details] [diff] [review] 1171758_1.patch Review of attachment 8624218 [details] [diff] [review]: ----------------------------------------------------------------- r=dkl
Attachment #8624218 -
Flags: review?(dkl) → review+
Reporter | ||
Comment 11•9 years ago
|
||
Somebody knows what would be the appropriated w-sec for this bug ?
Reporter | ||
Comment 12•9 years ago
|
||
@AlBillings: Any updates related bug bounty decision? Thought those decisions used to be done weekly, why is this taking that long ?
Comment 13•9 years ago
|
||
Hey Mario, We have a work week this week - that may be why :-) Gerv
Updated•9 years ago
|
Flags: needinfo?(dveditz)
Keywords: sec-moderate
Reporter | ||
Updated•9 years ago
|
Summary: Persistent xss is possible on Firefox → Persistent xss is possible on Firefox(BUG=3)
Summary: Persistent xss is possible on Firefox(BUG=3) → Persistent xss is possible on Firefox
Reporter | ||
Comment 23•9 years ago
|
||
@Byron Dude, just wanted to organize the bugs I reported since I've got some other interesting bugs to report. Why did you change them back ?
Assignee | ||
Comment 24•9 years ago
|
||
(In reply to Mario Gomes from comment #23) > @Byron Dude, just wanted to organize the bugs I reported since I've got some > other interesting bugs to report. Why did you change them back ? that sort of information doesn't belong in the bug's summary. depending on what you're trying to achieve the whiteboard field may be a better field (or a saved search, or bug tagging, or a bookmark).
Assignee | ||
Comment 26•9 years ago
|
||
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git a5f0c0c..09b4735 master -> master
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Flags: sec-bounty? → sec-bounty+
Comment 27•9 years ago
|
||
glob: re comment 25-- I thought that's what tags like "off-topic" are for?
Reporter | ||
Comment 28•9 years ago
|
||
Thanks for the bounty! :D
Assignee | ||
Comment 29•9 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #27) > glob: re comment 25-- I thought that's what tags like "off-topic" are for? i'm not sure if the contents of that thread belongs in public, so i erred on the side of caution and made it private. but, yes, generally the off-topic tag is suitable.
You need to log in
before you can comment on or make changes to this bug.
Description
•