1103360 - Scripts are getting rendered from image files

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P2)

Description

[Shinto K Anto]

Attachment: IMAGE-SRC.zip

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

Steps to reproduce:

I have created a gif/bmp file with an added line of JavaScript in it. (Appended a JavaScript and recompiled to create a new gif file)

If I call this gif file inside script tag, This scripts I added before compiling will get execute in the browser. 

This will be a blessing for hackers to exploit XSS by bypassing all same origin policies. He can upload these images and later can as harmful scripts in any attack scenarios. Since the scripts are getting loaded from same domain many of the filtering also can bypass. 

Check the attachment for POC. 


Actual results:

If I call this image file inside <script src=""> These java scripts are getting rendered in the browser irrespective of the content type. 

Suppose my modified image file is img.gif, The following query will render the image in html content. 
<img src="img.gif">

And by calling the same image inside a script tag, I can execute this javascript contents inside my gif files in browser. 
<script src="img.gif"></script>

Interesting thing is without calling any .js files or writing any JavaScript contents I can execute any JavaScript I want. I can bypass all the existing blacklisting mechanisms to protect against XSS. 

More details in the attachment.


Expected results:

Scripts shouldn't be loading from an image file. 
If the content type/extension of the src file calling is of an image then that shouldn't be rendering for scripts.

Comment 1

[Benjamin Smedberg]

Henri, do you know whether this behavior is specced and whether this is actually a bug?

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to Shinto K Anto from comment #0)
> If I call this gif file inside script tag, This scripts I added before
> compiling will get execute in the browser. 

Interesting trick. For those who wish to skip looking at the files:

Both GIF and BMP have magic numbers than consist of ASCII letters. In both cases, the next two bytes are variable: pixel width in the case of GIF and file size in the case of BMP. Thus, the creator of the file can choose the next two bytes to have the ASCII interpretation of "/*". The creator of the file then allows the usual file contents go inside the JS comment and then appends "*/=0;" to end the comment, to assign something in the variable whose name is the image file magic number ("GIF89a" or "BM") and terminate the statement. What follows next is the payload JS. 

> Interesting thing is without calling any .js files or writing any JavaScript
> contents I can execute any JavaScript I want. I can bypass all the existing
> blacklisting mechanisms to protect against XSS. 

Blacklisting is fundamentally broken as an XSS defense. What works is only allowing what's known to be safe.

In this case, the point where security breaks down is the point where the attacker gets to insert the script tag <script src=foo.gif></script> on the victim site. If a site allows an attacker to insert a script tag, everything is already lost. It's a detail whether the script payload comes from once the attacker gets to inject the tag.

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Henri, do you know whether this behavior is specced and whether this is
> actually a bug?

As far as I can tell, we are behaving per spec (https://html.spec.whatwg.org/multipage/scripting.html#the-script-element). Script loading ignores the MIME type from the Content-Type HTTP header. It only potentially takes the charset= parameter from Content-Type. The actual type comes from the HTML and defaults to text/javascript.

While the behavior certainly will surprise people, as noted above, to exploit this, the attacker has to get the site to refer to an image from <script src> and a site that allows attacker-controlled <script src> is very, very broken--regardless of whether the src points to an image or not.

Comment 3

[Benjamin Smedberg]

Closing bug per Henri.

Comment 5

[Shinto K Anto]

Can you tell me why the same page (poconcloud.html) is not rendering javascripts in Google chrome and IE 11 ?

Comment 6

[Shinto K Anto]

https://code.google.com/p/chromium/issues/detail?id=433049#c16

I had reported the same issue to google as well. They have accepted it and fixed it today. I still strongly feel this should be considered as a security flow here as well. :)

Comment 7

[ytrezq]

It works in ɪᴇ the same way. seems a bug from ᴡindows®.

Comment 8

[Virginia (please send need info request to Brindusa Tot)]

Hi,

I'm marking this ticket as Resolved - WFM as I understand this is an outdated issue.
Please reopen it in case this is still active.

Thanks,
Virginia