Works for me when I put that in the console on 54.0.2840.90; Ubuntu 14.04. Are you perhaps having an issue in a specific page? Can you provide a URI or the exact page?

<script>
Function("a=`","`,xss=1){alert(xss)")()
</script>

http://output.jsbin.com/kugofuh

This page pops up an alert for me. Does it not for you?

Also works for me on M54.

Ooops, read it the other way around.

Looks buggy.

We (correctly) parse the arguments to the function constructor as two separate strings, and any interpretation of the 2nd will (correctly) throw a syntax error. But when actually executing the function constructor, this fails and the content of the first changes the interpretation of the 2nd.

I suspect the problem is in CreateDynamicFunction in builtins-function.cc.

Not sure yet what to do with it.


@masa.sec: Thanks for being persistent. :-)

I have a fix in crrev.com/2533463002, but it's kinda lame & rather hacky in that it merely upgrades the 'combo breaker' in builtins-function.cc.

I'd think long-term we'd want a different approach for executing Function(...).


@jochen (or anyone else on this bug): Do you have an opinion [for|against] the proposed fix? If not, who would?

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/e0d608a2b1dcdd8a02c3d3db691bafec8461815a

commit e0d608a2b1dcdd8a02c3d3db691bafec8461815a
Author: vogelheim <vogelheim@chromium.org>
Date: Mon Nov 28 14:43:35 2016

Fix 'combo breaker' in CreateDynamicFunction to handle template literals.

BUG= chromium:663410 

Review-Url: https://codereview.chromium.org/2533463002
Cr-Commit-Position: refs/heads/master@{#41320}

[modify] https://crrev.com/e0d608a2b1dcdd8a02c3d3db691bafec8461815a/src/builtins/builtins-function.cc
[add] https://crrev.com/e0d608a2b1dcdd8a02c3d3db691bafec8461815a/test/mjsunit/regress-crbug-663410.js

+jwolfe, who's working on getting rid of the hacks altogether as part of https://bugs.chromium.org/p/v8/issues/detail?id=4958

#12: That'd be wonderful. Please let me know if I can help.

I'm declaring this one as fixed, then, if further work is to be tracked in  crbug.com/v8/4958 .

I have no idea what this issue want to prove? You are assume the attacker already can control the source of the at least one parameter and some part of the function body? In such case, the attacker can definitely do everything he want.

#15: I'm confused where the sudden attention comes from. This was closed 1.5y ago.

Also, I'm confused about the exact question. The reported behaviour was definitely buggy and violated the spec and hence needed fixing. I am grateful for the bug report.

Whether the reported issue increased the attack surface (in addition to being buggy) or not is, IMHO, a secondary question. That said, I could certainly imagine a library constructing a Function object from sanitized user input (e.g. an expression evaluator w/ user-supplied expressions, or somesuch), and in this case the sanitizer could possibly be tricked. No idea whether anyone does this, but I hear stranger things have been found in real-life JS code.