1711361 - eluminate.js shim can be made to execute random functions

Status: RESOLVED FIXED

(Web Compatibility :: Tooling & Investigations, defect)

Description

[Daniel Veditz [:dveditz]]

from https://twitter.com/shhnjk/status/1393692580907393028

The eluminate.js shim will execute any command put into the cmTagQueue array. The shim maps each of the expected commands to a noop function, but anything "extra" added will be executed if it's a valid function. In addition to the above example allowing a script to call alert(1), if future versions of the real eluminate.js add more commands they won't be mapped to the noop with the result that we'll try to execute a non-existing function and probably break the page.

I can't think of a way to use this maliciously at the moment since the only way to get these functions into cmTagQueue is from running script, which could just do whatever malicious thing it wanted to do.

Comment 1

[terjanq]

I can't think of a way to use this maliciously at the moment since the only way to get these functions into cmTagQueue is from running script, which could just do whatever malicious thing it wanted to do.

CSP can be bypassed with Prototype Pollution and HTML injection, as shown in the tweet.

Comment 2

[Frederik Braun [:freddy]]

Fair point. Let's dissect the attack tree to see if this raises the severity.

The attacker needs to

1. set the cmTagQueue variable
2. inject the eluminate library (HTML injection / XSS)

Step 1 can be achieved with a script injection, prototype pollution (DOM clobber doesn't work).
Step 2 can be achieved by injecting the script URL.
This either happens by guessing the moz-extension:// UUID, which is randomized per browser install (unlikely), but bypasses all CSP checks (by virtue of being a moz-extension URL). The script URL https://libs.coremetrics.com/eluminate.js might also be used, but that doesn't bypass CSP checks.

Oh, and if a website is using the actual eluminate library, they are already susceptible to this issue because the real-world eluminate library has the very same window[cmTagQueue[0][0]].apply(..) code.

With the (imho relatively strong) requirement of an injections and a prototype pollution (or two injections) and no proven way to guess the UUID, I think this qualifies as very, very low severity.

Comment 3

[Rob Wu [:robwu]]

There are ways to leak the UUID (e.g. via a stack trace). Here is an example to show the UUID can be leaked if someone is able to trigger the redirect to the extension resource:

data:text/html,<script>cmTagQueue=[["eval","alert(new Error().stack)"]]</script><script src="https://httpbingo.org/redirect-to?url=moz-extension://UUID_OF_WEBCOMPAT_ADDON/shims/eluminate.js"></script>

Linking to bug 1712096 for visibility; while that bug doesn't fix the issue here, the existence of that feature would allow the webcompat add-on to drop the usage of web_accessible_resources, which in turn would reduce the ease of exploitation of this issue.

Comment 4

[Thomas Wisniewski [:twisniewski]]

I have a patch in the works to limit cmTagQueue to only operate on the various Eluminate window functions, as that seems to be how it is generally meant to be used anyhow from samples I'm seeing online.

Beyond that, it seems as though we'll have to wait for bug 1712096 and/or other improvements to mitigate the moz-extension URL risks any further.

Comment 5

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1711361 - Have SmartBlock's Eluminate shim to treat the cmTagQueue as a no-op; r?robwu

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1b1d5428830a
Have SmartBlock's Eluminate shim to treat the cmTagQueue as a no-op; r=robwu,webcompat-reviewers,ksenia

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/1b1d5428830a