688167 - [SECURITY] XSS in IE7 via JS embedded in image

Status: RESOLVED WONTFIX

(Bugzilla :: Attachments & Requests, defect)

Description

[Anil Aphale]

Attachment: bugzilla XSS Vulnerability.pdf

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

Step1 :Uploaded image containing javascript as attachment for testcase after creating new bug.

Step2: Click on attachment or click on details

Step3: Javascript got executed(works with Internet Explorer 7)


 


Actual results:

Javascript Executed and cookie shows in popup message box.


Expected results:

Solution1 :Upload functionality should be filtering contents of the image\
Solution2 :Use HTTPOnly attribute with cookie
Solution3 :Uploaded attachment should be stored on other domain or server.

Comment 1

[Anil Aphale]

Attachment: testcase file

Comment 2

[Frédéric Buclin]

(In reply to Anil Aphale from comment #0)
> Solution1 :Upload functionality should be filtering contents of the image\

There is no need to do this, because we already do #2 and #3.

Comment 3

[Anil Aphale]

I am able retrieve cookies using Internet Explorer 7.

Comment 4

[Reed Loden [:reed]]

While the reporter isn't able to get any useful cookies (from the image in the PDF), he is still able to execute JS from an image. That seems less than optimal. Let's see if we can do anything about that.

Comment 5

[Frédéric Buclin]

This is a failure in the browser, not in Bugzilla. This is wontfix to me.

Comment 6

[Anil Aphale]

we can execute same attack with latest versions of IE as well...

Filteration should be on place with web application.

because bugzilla is trusted site and user may get exploited by visiting the trusted site.

Comment 7

[Anil Aphale]

Any updates on the patches for this??

Comment 8

[Michael Coates [:mcoates] (acct no longer active)]

How does this attack differ from uploading a malicious HTML file as an attachment? 

Is the uploaded image stored on a separate domain?

Comment 9

[Anil Aphale]

This is differ from uploading a malicious HTML file as the user take doubt on HTML file before clicking on it so chances decreases.

in case of image user generally dont take any doubt that this file can be malicious and chances of clicking on image file is always greater than the HTML file.

This vulnerability is not only limited for Executing Javascript to steal cookie but also malicious image file with redirection code to malicius web page, attacker can execute Active-X exploits.
he can also include Web Browser based exploits in image file to execute them on user context.

Comment 10

[:glob ✱]

(In reply to Michael Coates [:mcoates] from comment #8)
> Is the uploaded image stored on a separate domain?

yes; the image is displayed in a frame served from the attachment host.

eg. for the image attached to this bug, the frame's src is https://bug688167.bugzilla.mozilla.org/attachment.cgi?id=561491

Comment 11

[Michael Coates [:mcoates] (acct no longer active)]

If we have the same constraints in place for html and image files then I don't think there is any other work here.  HTML files and images can both be malicious. We've taken actions to move these attachments to a separate domain to eliminate session hijacking concerns. We also visually indicate if a user is new to bugzilla - which can be used by and individual to evaluate if they want to click on an attachment.

Comment 12

[Frédéric Buclin]

So we agree. Wontfix based on comments 2, 5 and 11. Images are not more dangerous than HTML files, and we already took actions to mitigate the problem, see comment 2.

Comment 13

[Max Kanat-Alexander]

  I would also like to take this opportunity to remind and reinforce the fact that any MIME type can potentially be dangerous (especially on IE), and that our behavior of always serving every single attachment--regardless of its mime type--from the attachment domain is in fact correct.