969037 - iFrameinjection initiated by JS should be prevented

Status: UNCONFIRMED

(Core :: General, defect)

Description

[Djfe]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

Just read this: http://blog.sucuri.net/2014/02/new-iframe-injections-leverage-png-image-metadata.html

and thought that it should be quite easy to save the user from exploits like this one


Actual results:

Firefox/its core executes iFrames that are created with javascript which leads to frameinjection -> drive-by downloads


Expected results:

js iFrames should be user-intiated like plugins (click to play) and popups are right now

or at least the iFrames which are invisible should be blocked this way as no normal website will place iFrames outside of the visible area (-1000px -1000px) especially not using javascript

to detect viruses/exploits like the one presented above is hard for antivirus software without causing performance issues

Mozilla should set a good example to convince other companies like Google and Microsoft to adopt the same code and make every normal website compatible with this

or there should be even a standard (WC3) revision for this as everything else which is harmless can get executed with ajax already

I'm sorry if the component "General" is not the right one for this issue, but I think that it concerns at least two components: "Javascript Engine" and "Layout: HTML Frames"

pls write your own feedback: What do you think about such a change? Is this incompatible with a standard or something? Or is it essentially to save the user from exploits

checking each file (not only imagefiles) for meta data which contains javascript is out of option I think (Antivirus solutions could do this but it would reduce the performance as said above)

Comment 1

[Djfe]

In addition:
changing the src attribute using js should be block as well as the creation of iframes using js

iFrames that are in the original sourcecode have to be checked by antivirus software still which should cause no additional issue (we don't want to block legal usage like YouTube comments (G+) and Google Ads etc.)

Comment 2

[Boris Zbarsky [:bzbarsky]]

> as no normal website will place iFrames outside of the visible area (-1000px -1000px)
> especially not using javascript

Sites (and more importantly libraries like jQuery) create hidden iframes all the time.  Using javascript.

> Is this incompatible with a standard or something? 

Yes, insofar as the standard says how DOM/layout should work and that specification requires being able to have hidden frames...

Comment 3

[Djfe]

mmh...so you think it would bombard the user with iFrame warnings? (pop-ups are a standard as well and still Mozilla implemented methods to prevent invisible execution of scripts etc. because it was misused. Or is the blocking of pop-ups part of the standard now?)

can you give an example what jquery uses iFrames in Firefox for what cannot get achieved with Ajax?

for me it's mostly a layout option without a technical background so I would appreciate it if you can explain this a bit further or give me a link with further informations so that I can look it up myself ;)

Comment 4

[Boris Zbarsky [:bzbarsky]]

> mmh...so you think it would bombard the user with iFrame warnings?

Yes.

> and still Mozilla implemented methods to prevent invisible execution of scripts

No, Mozilla implemented mitigation measures against malicious behavior that harmed users but was very rarely used by sites users cared about.  The iframe situation is different.

> can you give an example what jquery uses iFrames 

Sure.  The function following the comment at https://gist.github.com/rwaldron/8720084#file-jquery-js-L5432 is called on pretty much any jQuery page and creates an invisible iframe in many cases.

Comment 5

[Djfe]

does this iFrame workaround apply to Firefox or is Firefox able to detect the default display directly with elemdisplay() or actualdisplay()?

If Firefox doesn't use the iFrame because it is a workaround for other browsers then the example will be wrong.

Comment 6

[Djfe]

At least Thunderbird should prevent such iFrames in my opinion.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> does this iFrame workaround apply to Firefox

Yes.

> At least Thunderbird should prevent such iFrames in my opinion.

Thunderbird doesn't run script (unless you go out of your way to turn it on, which you shouldn't), so all this is totally irrelevant to Thunderbird.

Comment 8

[Djfe]

Mozilla could also work together with the W3C and the query developers to implement proper standards and replace these workarounds