952868 - Javascript executing itself from external iframes (serious danger)

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Andrew]

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

Steps to reproduce:

Open www.argim.net or any site that uses a RightMedia-based ad network (disabling the Request Desktop Site option) 


Actual results:

JavaScript alert() and confirm() functions with annoying code and URL redirections executed from the iframe ads automatically. Also APK file downloads from external sites executed automatically (extreme danger). ALL DOORS open for malicious JavaScript execution from JS in external iframes.


Expected results:

Ensure that iframe ads are NOT executing JavaScript stuff like alerts, redirections, or file downloads. All JavaScript from iframes from different domains MUST be IGNORED.

Comment 1

[Daniel Veditz [:dveditz]]

(In reply to Andrew from comment #0)
> Ensure that iframe ads are NOT executing JavaScript stuff like alerts,
> redirections, or file downloads. All JavaScript from iframes from different
> domains MUST be IGNORED.

That, unfortunately, violates web standards and will break many legitimate sites. Fake virus-warnings are a scummy kind of ad and you should complain to both argim.net and 360 mobi about it.

Automatically executing (opening?) APK files would be extremely unsafe, though many users would be protected by the default Android setting of only installing APKs from the Play store. That's not what I see from this ad: If I "fall for it" and click the button I get redirected to the play store. That's safe enough and allowed. Still quite scammy in this context, but not automatic.

On a different site that has .APK downloads, such as http://nightly.mozilla.org/, there does not appear to be anything asking the user to OK the download first. And once it's downloaded if a user clicks on it in the notification area that will kick off the install process (if the user allows installs from sites other than the Play store). At that point the user does get a chance to cancel out, but that seems pretty far into the process to catch attempts at a socially engineered install.

Comment 2

[Andrew]

Daniel, APK files were downloaded and saved automatically. But also the entire PAGE is redirected. Sin WHEN can Javascript redirect the parent window when the parent window is in a different domain? This is a bug because no desktop browser ever allows that.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Daniel Veditz [:dveditz] from comment #1)

> Automatically executing (opening?) APK files would be extremely unsafe,
> though many users would be protected by the default Android setting of only
> installing APKs from the Play store. That's not what I see from this ad: If
> I "fall for it" and click the button I get redirected to the play store.
> That's safe enough and allowed. Still quite scammy in this context, but not
> automatic.

We added some code to make sure the Firefox no longer automatically executes APK (or any) files. The user needs to open the download from the notification tray, or from the download manager.

> On a different site that has .APK downloads, such as
> http://nightly.mozilla.org/, there does not appear to be anything asking the
> user to OK the download first. And once it's downloaded if a user clicks on
> it in the notification area that will kick off the install process (if the
> user allows installs from sites other than the Play store). At that point
> the user does get a chance to cancel out, but that seems pretty far into the
> process to catch attempts at a socially engineered install.

I thought we had an open bug about adding a download prompt for certain file types, APK being the only one I can remember. Maybe Wes or Richard remember the bug.

Comment 4

[Richard Newman [:rnewman]]

(In reply to Mark Finkle (:mfinkle) from comment #3)

> I thought we had an open bug about adding a download prompt for certain file
> types, APK being the only one I can remember. Maybe Wes or Richard remember
> the bug.

You might be thinking of Bug 945429 Comment 11, which is a little different -- that's about downloading file: URIs, but we can certainly morph it. Not yet landed (other stuff came up).

(Vaguely related: Bug 950417 and Bug 950420 for XPIs.)

Comment 5

[Andrew]

The APK was not opened (thank God), otherwise I would have immediately uninstalled Firefox for good.

Regarding the URL redirection: The HTML5 specification specifies that a window A can change the location of another window B iff:

- The locations of A and B have the same origin, which is to say they have the same scheme, host, and port (http, stackoverflow.com, 80 for example), or
- B is a top-level window, and A is a window in a frame nested at some depth within B (direct child, child of a child, etc.), or
- B is a window opened using window.open and A can change the location of the window that opened B (so B is a popup opened by A, by a popup window opened by A, or at greater depth), or
- B isn't a top-level window, but its parent window, or its parent's parent window, or at some similar amount of parentage the locations of that window and A are same-origin ((Same origin is more complicated than this, but the embedded description above catches its essence and covers the most common cases.)

The above was taken from a post in StackOverflow.

NONE is the case for the ads in sites such as www.argim.net. Clearly there is no reason to allow a parent redirection in this case, yet Firefox is happily allowing all types of redirections and window opening freely, from an iframe with different domain. The browser is and will be unusable until this is solved, and I hope to see that someone understood the issue, regardless of it being investigated or not in the near future. (I'm not crazy, my mother had me tested :)

Thanks, and happy new year (if applicable).

Comment 6

[Boris Zbarsky [:bzbarsky]]

> This is a bug because no desktop browser ever allows that.

Every single desktop browser allows this, because it's sadly needed for web compat.

> NONE is the case for the ads in sites such as www.argim.net.

How not?  That's exactly the "B is a top-level window, and A is a window in a frame nested at some depth within B" case, isn't it?

Comment 7

[Andrew]

(In reply to Boris Zbarsky [:bz] from comment #6)

> > NONE is the case for the ads in sites such as www.argim.net.
> 
> How not?  That's exactly the "B is a top-level window, and A is a window in
> a frame nested at some depth within B" case, isn't it?

B is not a top-level window, A is the top level window and B is an iframe nested at some depth within A. Yet B is changing the URL of A, and no serious browser would ever allow that.

Anyway, this is not going anywhere. I'll stick with Opera browser indefinitely.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Yet B is changing the URL of A

If you actually look at what the spec says, it says "A can change the location of another window B" in some cases.  And one of those cases is if "B is a top-level window, and A is a window in a frame".

So in your case, the spec's "A" is the ad and the spec's "B" is the www.argim.net page, which is in fact a toplevel window, so A can navigate B.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Also, note that a site that wants to prevent ad iframes from executing JS just needs to sandbox them.

Comment 10

[Wesley Johnston (:wesj)]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> Automatically executing (opening?) APK files would be extremely unsafe,
> though many users would be protected by the default Android setting of only
> installing APKs from the Play store. 

Just to be clear, "executing" an APK on Android means handing it to the installer to be installed. The installer unzips it, reads the manifest, and displays a prompt to the user based on what's inside. It isn't allowed to actually run any executable code of its own until the user has been through this (in addition to flipping the hard to find pref you mentioned). Calling it "extremely unsafe" seems like a stretch in my opinion. We're not launching an executable.

We currently show a prompt if there are other apps that can open a download (and hand them the url in that case). If there aren't any we'll just download the thing. Tapping the notification will launch the installer app with the apk. i.e. we currently only sometimes a download prompt. Tapping the "download complete" notification will always send the file to the intent system.

Comment 11

[Matt Wobensmith [:mwobensmith][:matt:]]

Based on comment 8, the iframe/window renavigation appears to be working as designed.

Comment 9 has a good suggestion for page authors who wish to sandbox iframes that might have malicious script.

Comment 10 indicates that while we may download an APK, we do not in fact execute its contents.

Based on the above, I don't see anything actionable here.

Comment 12

[Andrew]

I have added the sandbox attribute to the iframe ads. Even if it does not prevent Javascript alerts, at least no more URL redirections are launched.