Mario Gomes Reporter
	Description • 8 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36

Steps to reproduce:

Hey,

it's possible to clickjack using through the pages "view all" and "details", this vulnerability represents a risk once there's the possibility to "edit" all the informations of a by using the "suspicious action" page, by clicking on one single button is possible to a bug entirely. 

To patch this vulnerability you may want to set "x-frame-options" to 'deny'. 

PoC: https://bugzilla-dev.allizom.org/attachment.cgi?id=8591830&action=edit

Cheers,
Mario

	Daniel Veditz [:dveditz]
	Comment 1 • 8 years ago

I can't see that PoC because I've changed my BMO password since last year and can't remember the old one, and my unprivileged test accounts can't see that private bug. Since email is disabled I can't go through the "forgot my password" flow. You could CC my dveditz at yahoo.com account.

There seem to be a few words missing from your description and I'm not quite sure what you're saying. The view-all and details pages seem to have X-Frame-Options: SAMEORIGIN (at least in BMO; all attachments seem to be deleted on bugzilla-dev). the bmoattachments domain does not, because the attachments themselves need to be framed by the BMO page (and in any case can't do any dangerous actions because they're a separate origin). I don't see any dangerous actions that could be click-jacked on the View-all page (even if it were missing XFO). Maybe the clue I need is the missing verb in "possible to a bug entirely", but information on which button would help too. Might be perfectly clear from the PoC if I could see it.

	Dylan Hardison [:dylan] (he/him)
	Comment 2 • 8 years ago

    # Add X-Frame-Options header to prevent framing and subsequent
    # possible clickjacking problems.
    unless ($self->url_is_attachment_base) {
        unshift(@_, '-x_frame_options' => 'SAMEORIGIN');
    }

Is what we have. It is possible this is not sent for dev. I am out sick but I will poke at this from my phone.

	Mario Gomes Reporter
	Comment 3 • 8 years ago

Sorry about that, I typed the description through my phone and had a hard time trying to struggle the "speel checker" \o/

I changed the poc into a public bug, please visit: https://bugzilla-dev.allizom.org/attachment.cgi?id=8591832&action=edit

The x-frame-optins:SAMEORIGIN is being properly displayed. The problem is that these two pages frames the attachment, which means that If attachments contains the <iframe> pointing to any where at "bugzilla.mozilla.org" it'll be displayed while it's been viewed through that both pages(try the poc you'll get what I mean). 

Due to the non-use of "x-frame-options:deny" if a user visits "details" page of a specially crafted IFRAME and gives one simple click inside the attachment this might result on a CSRF attack.

	David Lawrence [:dkl] Assignee
	Comment 4 • 8 years ago

(In reply to Dylan William Hardison [:dylan] from comment #2)
>     # Add X-Frame-Options header to prevent framing and subsequent
>     # possible clickjacking problems.
>     unless ($self->url_is_attachment_base) {
>         unshift(@_, '-x_frame_options' => 'SAMEORIGIN');
>     }
> 
> Is what we have. It is possible this is not sent for dev. I am out sick but
> I will poke at this from my phone.

We do serve SAMEORIGIN from bugzilla-dev.allizom.org just like production. Thing to note here is we do not serve attachments from a different domain on bugzilla-dev like we do production so this is why the exploit may work. So probably not an issue for production anyway. It has been known for a long time, serving attachments from the same domain is a foot-gun.

That being said, I am not able to make the PoC work on bugzilla-dev myself. When I click the iframe contents, I do not see the summary being updated for the bug id that is in the PoC attachment.

dkl

	Mario Gomes Reporter
	Comment 5 • 8 years ago

@dkl try this new PoC: https://bugzilla-dev.allizom.org/attachment.cgi?id=8591833&action=edit

I'll create an random number and add it to the new summary then you'll notice when the exploit works.

	David Lawrence [:dkl] Assignee
	Comment 6 • 8 years ago

(In reply to Mario Gomes from comment #5)
> @dkl try this new PoC:
> https://bugzilla-dev.allizom.org/attachment.cgi?id=8591833&action=edit
> 
> I'll create an random number and add it to the new summary then you'll
> notice when the exploit works.

Ok so I get the popup with the random number, when i click OK, it tries to process_bug.cgi making the change but is blocked due to missing CSRF token. Are you able to do the change without the token cause otherwise the process_bug.cgi page is properly blocking the change which makes this less server IMO.

	Mario Gomes Reporter
	Comment 7 • 8 years ago

@dkl the goal of the poc is:
1. Force a request to "process.cgi" without a CSRF Token, this will force the "suspicious action" page to show up
2. This page has a button "Yes, Confirm Changes", which can be clickjacked.
3. Then when the victim clicks in "yes, confirm changes" the attack will be concluded.

	Mario Gomes Reporter
	Comment 8 • 8 years ago

The main problem is that the page "suspicios action" page has the "X-FRAME-OPTIONS:SAMEORIGN", this page shows a when something goes wrong when validating the CSRF Token, I think it shouldnt be possible to frame such page(as this can contribute for a clickjacking attack). 

If you guys agree with me, a good patch for this could be "X-FRAME-OPTIONS:DENY" only the "suspicios action" page, once it's only page that can real cause some harm.

	Mario Gomes Reporter
	Comment 9 • 8 years ago

So... Has been vulnerability been confirmed?

	Frédéric Buclin
	Comment 10 • 8 years ago

You already reported this bug, and this problem is fixed since Bugzilla 5.0.

	Dylan Hardison [:dylan] (he/him)
	Comment 11 • 8 years ago

The fix in bug 728892 was never merged into bmo.

	Mario Gomes Reporter
	Comment 12 • 8 years ago

Any chance this would get a security rate?

	David Lawrence [:dkl] Assignee
	Comment 13 • 8 years ago

(In reply to Mario Gomes from comment #12)
> Any chance this would get a security rate?

Not sure. Up to security-team how to handle this one.

Taking bug and will commit the fix to BMO.

dkl

	Dylan Hardison [:dylan] (he/him)
	Comment 15 • 8 years ago

Comment on attachment 8744084 [details] [diff] [review]
1266167_1.patch

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

r=dylan

	David Lawrence [:dkl] Assignee
	Comment 16 • 8 years ago

To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   d447aed..dab15f5  master -> master

And this has been pushed to production as well.

dkl

	Al Billings [:abillings - ex-MoCo]
	Comment 17 • 8 years ago

Adam, can you look at this and see about assigning a security rating?

	Mario Gomes Reporter
	Comment 18 • 8 years ago

Apparently Adam cant set the sec-rate right now, can anybody else do it??

	Adam Muntner [:adamm] (use NEEDINFO)
	Comment 19 • 8 years ago

I set risk as sec-moderate due to the missing CSRF token and suspicious action page. I'd consider it a lower risk sec-moderate bug because (hopefully) most Bugzilla users would know that something bad was going on, lowering the likelihood of exploitation. 

It was a nice bug though Mario, thanks for noticing we didn't push the change to BMO. If this bug was for a shopping site or online banking instead of a site where technical people work on stuff that has to be protected about clickjacking, the likelihood of someone falling for it even with the warning would be much higher.

Keep an eye on the bounty faq page, a bunch more hosts will be listed once the changes go live.

	Mario Gomes Reporter
	Comment 20 • 8 years ago

@Adam, does that mean this bug isn't eligible for a bounty?

	Al Billings [:abillings - ex-MoCo]
	Comment 21 • 8 years ago

Mario, bounty questions should be emailed to security@mozilla.org in general. 

Bounty committee decided to pay $500 on this.

	Mario Gomes Reporter
	Comment 22 • 8 years ago

thank you!