Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prototype Pollution with Remote Code Execution #1495

Closed
nknapp opened this issue Feb 7, 2019 · 5 comments

Comments

@nknapp
Copy link
Collaborator

commented Feb 7, 2019

At the beginning of the year, we were notified by npm-security about a vulnerablity that allowed template creators to execute arbitrary JavaScript code.

By accessing the object's constructor, it is possible to fabricate arbitrary and execute Functions.

In an environment, where Handlebars is executed in a NodeJS environment, this means that anybody who can modify Handlebars templates, can also access the file system, spawn sub-processes and open network connections from the NodeJS-server.

The vulnerabilty has been fixed in version 4.0.13 and 4.1.0 by forbidding access to the constructor.
So far, we have not been able to reproduce the vulnerability with 3.x versions.

https://www.npmjs.com/advisories/755

nknapp added a commit that referenced this issue Feb 7, 2019
This commit fixes a Remote Code Execution (RCE) reported by
npm-security. Access to non-enumerable "constructor"-properties
is now prohibited by the compiled template-code, because this
the first step on the way to creating and execution arbitrary
JavaScript code.
The vulnerability affects systems where an attacker is allowed to
inject templates into the Handlebars setup.
Further details of the attack may be disclosed by npm-security.

Closes #1267
Closes #1495
nknapp added a commit that referenced this issue Feb 7, 2019
This commit fixes a Remote Code Execution (RCE) reported by
npm-security. Access to non-enumerable "constructor"-properties
is now prohibited by the compiled template-code, because this
the first step on the way to creating and execution arbitrary
JavaScript code.
The vulnerability affects systems where an attacker is allowed to
inject templates into the Handlebars setup.
Further details of the attack may be disclosed by npm-security.

Closes #1267
Closes #1495
nknapp added a commit that referenced this issue Feb 7, 2019
This commit fixes a Remote Code Execution (RCE) reported by
npm-security. Access to non-enumerable "constructor"-properties
is now prohibited by the compiled template-code, because this
the first step on the way to creating and execution arbitrary
JavaScript code.
The vulnerability affects systems where an attacker is allowed to
inject templates into the Handlebars setup.
Further details of the attack may be disclosed by npm-security.

Closes #1267
Closes #1495
@nknapp nknapp changed the title Security issue (details follow) Prototype Pollution with Remote Code Execution Feb 15, 2019
@nknapp nknapp closed this Feb 15, 2019
@nknapp nknapp reopened this Apr 13, 2019
@nknapp

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 13, 2019

Version 4.0.14 and 4.1.2 contain fixes for an attack vector that was not considered in 4.1.0 and 4.0.13.

Another more complete fix will follow.

@nknapp nknapp closed this Apr 13, 2019
ghinda added a commit to gorgias/gorgias-chrome that referenced this issue Jun 28, 2019
@ghinda ghinda referenced this issue Jun 28, 2019
ghinda added a commit to gorgias/gorgias-chrome that referenced this issue Jun 28, 2019
* Change amplitude project keys.
* Initialize amplitude only once in `amplitude.js`.
* Upgrade Handlebars to fix security issue:
wycats/handlebars.js#1495
@laserlemon

This comment has been minimized.

Copy link

commented Jul 15, 2019

@nknapp 👋 I'm on the GitHub team responsible for security vulnerability alerting. I think our information on this vulnerability needs to be corrected and I could use your help.

I'm considering updating our information to include these vulnerable ranges:

Vulnerable: < 3.0.7
Patched: 3.0.7

Vulnerable: >= 4.0.0, < 4.0.14
Patched: 4.0.14

Vulnerable: >= 4.1.0, < 4.1.2
Patched: 4.1.2

Does that ☝️ seem right? Thank you for your help and I will work to get these alerts updated as soon as possible today.

@dougwilson

This comment has been minimized.

Copy link

commented Jul 15, 2019

Hi @laserlemon 👋 . So the RCE (which is what has been popping up in GitHub) was tracked with the announcement in #1495 from the handlebars project. It was ultimately patched in the 4.0.14 and the 4.1.2 versions. I'm not 100% sure when the bug was introduced (as in the lower ranges), but npm has their advisory at #1495 which seems to indicate the range you have above, except the for the 3.0.7. I see that was released 15 days ago with the patch (bae88eb) so I think you have the right range there for the RCE issue. I see you also commented on the handlebars announcement issue as well, so ideally the handlebars team itself can directly confirm 👍

Thanks for taking a look into this ❤️

@laserlemon

This comment has been minimized.

Copy link

commented Jul 15, 2019

@dougwilson Thank you! ❤️

We've updated our GitHub security advisory to contain the three vulnerable version ranges described above. Inaccurate alerts were automatically removed and new alerts are in the process of being created.

If anybody still has an inaccurate alert or is missing an alert in 48 hours, please reach out!

@nknapp

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 19, 2019

Thank you @dougwilson for the clarifications. It represents more or less my level of knowledge.

Perhaps, I can give a little more details to the affected legacy versions: The published exploits don't work on a plain Handlebars 3.x installation, because the #with helper does not support block-parameters in this version. {{#with this as |obj|}} ... {{/with}} does not set obj inside the with block, but the published exploit requires this to work.

For 3.0.0 <= x < 3.0.7, the exploit will work in cases where the #with-helper is overwritten with a custom #with helper that supports block parameters (although I have not tested this myself).

Prior to 3.0, there is no support for block-parameters at all, so the published exploits don't work.

Finally, I have not looked very hard for ways to exploit the prototype-pollution without block-parameters, but I cannot exclude the possibility that an exploit exists.

So the ranges you provide seem to be reasonable.

/cc @laserlemon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.