Mario Gomes Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Steps to reproduce:

Hi,

I have found a open redirect bugs that could allow attacker's trick user's and possibly steal their accounts. 
In order to protect your user's you guys could add the attribute 'rel=noreferrer' inside the anchor tag and I'll avoid this attack.

Reproduce:
1. Click in the 'URL' field of this bug.
2. see you'll be redirected into my poc and a alert will be prompted inside of the buzilla tab, requesting user's  password... as it's prompted inside bugzilla's tag the user will trust on it and type its password.
3. user's password is stolen.

to patch this add 'rel=noreferrer' into the anchor tag.

Wonder if this bug eligible for a bounty?

Cheers,

	Gervase Markham [:gerv]
	Comment 1 • 10 years ago

The URL field is not an "open redirect", it's simply the ability to add a URL to the bug. People who use Bugzilla understand what happens when you click on URLs.

Adding rel=noreferrer won't help, because if the attacker knows the URL they have put into Bugzilla, they will just make it do the same thing anyway.

This is not a bug.

Gerv

	Mario Gomes Reporter
	Comment 2 • 10 years ago

Have you at least tried to run the poc?? 'Cause it looks like that you haven't! -.- 

First, once you clicked in the link a new tab will open, through this tag I can redirect the buzilla 'tab' into anywhere.

Nobody's so idiot to go to 'anything.com' and type its bugzilla password there, but i'm pretty sure that prompting a password alert inside a bugzilla tab, like this exploit does... it's most likely to get its credentials!

Not everybody that uses bugzilla are aware about 'javascript' tricks!

	Daniel Veditz [:dveditz]
	Comment 3 • 10 years ago

No one (who has any worthwhile bugzilla privs) would enter their password into a JavaScript prompt(), but I'll grant that an actual attack would create a page that actually looks like the bugzilla bug. Maybe you could register bugzilla.mozlla.com or other typo to host the attack for extra similitude. Of course it would be a bit suspicious that bugzilla would suddenly want my password when I opened someone's testcase.

I've nominated this for the bounty as requested, but as a jazzed-up phishing attack I don't think it's likely to be eligible.

Not really sure it's fixable, that's currently just the way opening links in new tabs works. It would take a change in browsers to fix (all of them) and possibly introduce breakage to currently-working sites.

	Frédéric Buclin Assignee
	Comment 4 • 10 years ago

How is that different from attaching a HTML page with JS code in it?

	Frédéric Buclin Assignee
	Comment 5 • 10 years ago

And how is that different from pasting the URL in a comment directly?

	:glob ✱
	Comment 6 • 10 years ago

dveditz: are you able to answer frédétic's questions in comments 4 and 5?

	Daniel Veditz [:dveditz]
	Comment 7 • 10 years ago

(In reply to Frédéric Buclin)
> How is that different from attaching a HTML page with JS code in it?
> And how is that different from pasting the URL in a comment directly?

It's not too different. The "twist" here is that the URL field opens a new tab, and users might be completely unaware that content can use window.opener to modify the original bug. If you click on a comment link or testcase and simply navigate there you clearly have to be on your guard. If a user clicks on the URL field and doesn't otherwise touch the original bug's tab they might more easily accept that any changes that happened to the original bug tab (not the new URL's tab) were done by bugzilla itself. 

Just another tool in the social engineering arsenal. Would be nice if there were such a thing as "rel=noopener" (noreference?) that could be put on such links. I'm sure bugzilla's not the only site that could benefit (in fact, if it weren't for potential bustage I'd turn off opener for links unless sites positively indicated they wanted it).

It doesn't increase the risk enough to make me want to rate it any higher as a security bug. I also don't think there's any reasonable way to fix this on bugzilla short of a browser change like that.

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

(00:55:35) dveditz: I think you could probably just unhide the bug

	Mario Gomes Reporter
	Comment 9 • 10 years ago

> Just another tool in the social engineering arsenal. Would be nice if there
> were such a thing as "rel=noopener" (noreference?) that could be put on such

You can use 'rel=noreferrer'. It sets 'window.opener' to null!

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

(In reply to Mario Gomes from comment #9)
> You can use 'rel=noreferrer'. It sets 'window.opener' to null!

Yes, Mario is right, see https://html.spec.whatwg.org/multipage/semantics.html#link-type-noreferrer:

"If a user agent follows a link defined by an a or area element that has the noreferrer keyword, the user agent must not include a Referer (sic) HTTP header (or equivalent for other protocols) in the request.

This keyword also causes the opener attribute to remain null if the hyperlink creates a new browsing context."


Firefox supports rel=noreferrer since Firefox 33, see bug 530396. And it also sets window.opener = null. Bug 1031264 improves this a bit further in Firefox 37 by also considering rel=noreferrer when a user does a middle-click on a link.

WebKit and Chromium support rel=noreferrer for much longer:

https://code.google.com/p/chromium/issues/detail?id=69267
https://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/

rel=noreferrer is part of HTML5 and so we cannot backport this fix to Bugzilla 4.x, which still use HTML4.

	Frédéric Buclin Assignee
	Comment 11 • 10 years ago

As Firefox 37 also supports rel=noreferrer for middle-clicks, I included it with all links to bug_file_loc.

	Frédéric Buclin Assignee
	Comment 12 • 10 years ago

Minor indentation fix.

	Gervase Markham [:gerv]
	Comment 13 • 10 years ago

Comment on attachment 8541239 [details] [diff] [review]
patch, v1

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

r=gerv. I don't know how much it will actively help, but I don't think it can break anything.

Gerv

	Frédéric Buclin Assignee
	Comment 14 • 10 years ago

I did some testing, and you can actually do pretty bad things when exploiting window.opener:

- edit the current bug on behalf of the victim (the one clicking on the link in the URL field). This lets the attacker do some actions that he couldn't do due to a lack of privileges (e.g. no editbugs or canconfirm privs).

- get information about other bugs the attacker cannot see but that the victim can see. The attacker can create as many iframes as he wants in the original bug (SAMEORIGIN is respected), load other bugs in them, and then CC himself to these bugs or get bugs data back.


No idea how to fix that in Bugzilla 4.x as they still use HTML4. I suppose we could use the same patch, and hope that the browsers will respect rel="noreferrer" anyway.

	Frédéric Buclin Assignee
	Comment 15 • 10 years ago

(In reply to Frédéric Buclin from comment #14)
> No idea how to fix that in Bugzilla 4.x as they still use HTML4. I suppose
> we could use the same patch, and hope that the browsers will respect
> rel="noreferrer" anyway.

... or remove target="_blank", which also fixes the problem.

	Mario Gomes Reporter
	Comment 16 • 10 years ago

Really?? How could I do such things by using this window.opener bug? I'm still tryin' to figure it out. Could do please explain it a little bi more?

(In reply to Frédéric Buclin from comment #14)
> I did some testing, and you can actually do pretty bad things when
> exploiting window.opener:
> 
> - edit the current bug on behalf of the victim (the one clicking on the link
> in the URL field). This lets the attacker do some actions that he couldn't
> do due to a lack of privileges (e.g. no editbugs or canconfirm privs).
> 
> - get information about other bugs the attacker cannot see but that the
> victim can see. The attacker can create as many iframes as he wants in the
> original bug (SAMEORIGIN is respected), load other bugs in them, and then CC
> himself to these bugs or get bugs data back.

	Mario Gomes Reporter
	Comment 17 • 10 years ago

I meant... * Could you please explain it a little bit more?

	Gervase Markham [:gerv]
	Comment 18 • 10 years ago

(In reply to Frédéric Buclin from comment #14) 
> No idea how to fix that in Bugzilla 4.x as they still use HTML4. I suppose
> we could use the same patch, and hope that the browsers will respect
> rel="noreferrer" anyway.

I would be astonished if Gecko refused to recognise new features defined in the HTML5 standard if the document had an HTML4 doctype. (If behaviours were conflicting, perhaps, but not if it's something new.)

Gerv

	Frédéric Buclin Assignee
	Comment 19 • 10 years ago

My testcase gets some data about this bug + another security bug. I commented out the line which commits changes to this bug to not spam everybody, but it works.

	Frédéric Buclin Assignee
	Comment 20 • 10 years ago

Ah, it doesn't work here. I wonder if it only worked because I was using it locally.

	Frédéric Buclin Assignee
	Comment 21 • 10 years ago

Hum, or because the domain name is different, which is good.

	Mario Gomes Reporter
	Comment 22 • 10 years ago

Yeah... It'd be awesome if I could access different domains data through an 'window.opener', unfortunately same orign policy denies it. All we can do is an "window.opener.location = url" anything else will be blocked by SOP.

So that is not much severe as I thought.

	Frédéric Buclin Assignee
	Comment 23 • 10 years ago

(In reply to Mario Gomes from comment #22)
> So that is not much severe as I thought.

Yes, correct. I had my HTML page on the same domain as my Bugzilla installation, which is why it worked. So it's not a blocker nor a security bug. Good!

	Frédéric Buclin Assignee
	Comment 24 • 10 years ago

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   fc6271c..26db658  master -> master

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   e82a813..a5758fa  5.0 -> 5.0

	Daniel Veditz [:dveditz]
	Comment 25 • 10 years ago

(In reply to Frédéric Buclin from comment #10)
> rel=noreferrer is part of HTML5 and so we cannot backport this fix to
> Bugzilla 4.x, which still use HTML4.

I don't understand. It's just an attribute that will do something in browsers which understand it, will be ignored in browsers that don't, and doesn't affect the functionality of bugzilla itself either way. Is there some "must pass a verifier" checkbox or something?

	Daniel Veditz [:dveditz]
	Comment 26 • 10 years ago

As a minor spoofing issue this does not qualify for a Web Bug Bounty.