1171758 - Persistent xss is possible on Firefox

Status: RESOLVED FIXED

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

Description

[Mario Gomes]

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

Comment 1

[Mario Gomes]

Attachment: screenshot

Comment 2

[Gervase Markham [:gerv]]

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

Comment 3

[Mario Gomes]

Isn't anyone going to work in this issue ? Has it been confirmed ?

Comment 4

[Gervase Markham [:gerv]]

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

Comment 5

[Mario Gomes]

(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

[Gervase Markham [:gerv]]

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

Comment 7

[Mario Gomes]

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

Comment 8

[Mario Gomes]

(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

Comment 9

[:glob ✱]

Attachment: 1171758_1.patch

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.

Comment 10

[David Lawrence [:dkl]]

Comment on attachment 8624218 [details] [diff] [review]
1171758_1.patch

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

r=dkl

Comment 11

[Mario Gomes]

Somebody knows what would be the appropriated w-sec for this bug ?

Comment 12

[Mario Gomes]

@AlBillings: Any updates related bug bounty decision? Thought those decisions used to be done weekly, why is this taking that long ?

Comment 13

[Gervase Markham [:gerv]]

Hey Mario,

We have a work week this week - that may be why :-)

Gerv

Comment 23

[Mario Gomes]

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

Comment 24

[:glob ✱]

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

Comment 26

[:glob ✱]

To ssh://[e-mail]/webtools/bmo/bugzilla.git
   a5f0c0c..09b4735  master -> master

Comment 27

[Daniel Veditz [:dveditz]]

glob: re comment 25-- I thought that's what tags like "off-topic" are for?

Comment 28

[Mario Gomes]

Thanks for the bounty! :D

Comment 29

[:glob ✱]

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