If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Clickjacking in Bugzilla Attached could allow steal source code of attachments.

RESOLVED INVALID

Status

()

Bugzilla
Attachments & Requests
RESOLVED INVALID
6 years ago
5 years ago

People

(Reporter: x, Unassigned)

Tracking

Bug Flags:
blocking4.2 -

Details

Attachments

(3 attachments, 1 obsolete attachment)

Created attachment 596984 [details]
Basic PoC.html

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.20 (KHTML, like Gecko) Chrome/19.0.1036.7 Safari/535.20

Steps to reproduce:

Hello,

Clickjacking on attachment viewer could allow attackers get content of attachment.

Reproduce:
1. Open PoC.html using Firefox.
2. Drag the text in white box.
3. See the content of attachment.

Cheers,
Mario.
Summary: Clickjacking in Bugzilla Attached could allow steal → Clickjacking in Bugzilla Attached could allow steal source code of attachments.

Updated

6 years ago
Attachment #596984 - Attachment mime type: text/plain → text/html

Comment 1

6 years ago
Your PoC seems broken.
Assignee: general → attach-and-request
Component: Bugzilla-General → Attachments & Requests
Are you logged in bugzilla.mozilla.org?Are you using Firefox?

Comment 3

6 years ago
(In reply to Mario Gomes from comment #2)
> Are you logged in bugzilla.mozilla.org?Are you using Firefox?

Of course I'm logged in, else I couldn't access this bug. :) And yes, I'm using Firefox 10.
lol... or you could have convinced the real "Frederic" to visit a page with the exploit, and force him to make that comment, or elevate their privileges bugzilla as admin. So, changing its name to the "Frederic Buclin" and cheating everybody. ;)
Created attachment 597183 [details]
Basic PoC(fixed the problem).

Fixed PoC.
Attachment #596984 - Attachment is obsolete: true
Comment on attachment 597183 [details]
Basic PoC(fixed the problem).

Verifying no malicious code, just a POC - setting to text/html (which is presumably required for the POC to work).

Gerv
Attachment #597183 - Attachment mime type: text/plain → text/html
Mario: it looks like you are saying that if you drag and drop attachment content out of an iframe into another frame, JS running in that frame has access to it. This seems like it's working as designed. Are you saying the risk is that people could be fooled into doing such a drag and drop operation without being able to see the content they are drag/dropping?

If so, how does one block such operations?

Gerv
Yes, the exploitation of this vulnerability to be used, such as a Fake Captcha that forces the victim to copy the contents of the box.

To resolve this problem, just add the header "X-FRAME-OPTIONS: SAMEORIGIN" thus not allow the page is viewed by an IFRAME.

(In reply to Gervase Markham [:gerv] from comment #7)
> Mario: it looks like you are saying that if you drag and drop attachment
> content out of an iframe into another frame, JS running in that frame has
> access to it. This seems like it's working as designed. Are you saying the
> risk is that people could be fooled into doing such a drag and drop
> operation without being able to see the content they are drag/dropping?
> 
> If so, how does one block such operations?
> 
> Gerv
But we do make attachments available in non-same-origin iframes, e.g.:

https://bugzilla.mozilla.org/attachment.cgi?id=593295&action=edit
which frames:
https://bug671634.bugzilla.mozilla.org/attachment.cgi?id=593295

So what we need is for 
https://bug671634.bugzilla.mozilla.org/attachment.cgi?id=593295
to be frameable by
https://bugzilla.mozilla.org/
but not by
https://<anything>.bugzilla.mozilla.org/

Gerv
Oh yes, if you add the X-FRAME-OPTIONS will have problems with https://bugzilla.mozilla.org/attachment.cgi?id=593295&action=edit. 

Or you could use security tokens, allows the page to be seen by an IFRAME only if the security token is correct.
bz, gavin: I see you've been doing work on cross-site drag and drop XSS in various security bugs. Any chance of some advice on how to mitigate the problem here? Is Firefox going to change to disallow this, or is it up to sites to take steps like X-FRAME-OPTIONS? What about Bugzilla's circumstances? We put attachments on a different domain as a security measure, and now we find that implementing a different security measure won't work because of that architecture!

Gerv
Flags: blocking4.2?

Comment 12

6 years ago
I honestly don't consider that drag and drop, i.e. actions which require an explicit action from the user, blocks 4.2. Also, when I view the attachment, I don't see the content of the attachment, so it seems the PoC still doesn't work.
Flags: blocking4.2? → blocking4.2-
Created attachment 597463 [details]
Screenshot.

Comment 14

6 years ago
But what do you get when you click "Go"? Isn't the content of the attachment supposed to appear in the popup?
When clicking "Go!" or simply dropping the content frame have access to the contents of the attachment. In a real attack page could use it as a Fake Captcha forcing User to drag or copy the contents of the IFRAME.

A fix for this, as I said is to use security tokens when the iframe page is opened in a "attachment.cgi?id=some_attachment_id&action=edit", so the page can only be seen by an IFRAME when the security token is correct.

Comment 16

6 years ago
This doesn't answer my question. How can I check that your PoC works? Why not paste the data in the popup, so that I can make sure data has reallay been collected?
Created attachment 597901 [details]
Demonstration Video(Frederic see this).
Question: How can I check that your PoC works?
Response: Open the PC when you are logged in Bugzilla, and drag (or copy) the code of the IFRAME to the text box, click in "Go!" and see the alert.

Question: Why not paste the data in the popup, so that I can make sure data has really been collected?
Response: Paste or drag does not matter, what matters is that the code is in the text box.
Correction:

Question: How can I check that your PoC works?
Response: Open the PoC when you are logged in Bugzilla, and drag (or copy) the code of the IFRAME to the text box, click in "Go!" and see the alert.
Why do you think I would put malicious codes in PoC? 

(In reply to Gervase Markham [:gerv] from comment #6)
> Comment on attachment 597183 [details]
> Basic PoC(fixed the problem).
> 
> Verifying no malicious code, just a POC - setting to text/html (which is
> presumably required for the POC to work).
> 
> Gerv
Summary: Clickjacking in Bugzilla Attached could allow steal source code of attachments. → Clickjacking in Bugzilla Attached could allow steal source code of attachments.("'</script/>"')
Summary: Clickjacking in Bugzilla Attached could allow steal source code of attachments.("'</script/>"') → Clickjacking in Bugzilla Attached could allow steal source code of attachments.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID

Comment 21

6 years ago
Why is this bug suddenly marked as invalid without any explanation?
don't works more. :(

Updated

6 years ago
Group: bugzilla-security

Updated

5 years ago
Duplicate of this bug: 761033
You need to log in before you can comment on or make changes to this bug.