-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Prevent prototype pollution chaining to code execution via _.template #4355
Prevent prototype pollution chaining to code execution via _.template #4355
Conversation
... and not via its prototype, as that enables chaining a prototype pollution into arbitrary code execution.
Ah, I thought the one raised by |
@jdalton Great, thanks for the quick response :) I adjusted the regexp to strip all |
lodash.js
Outdated
('sourceURL' in options | ||
? options.sourceURL | ||
(hasOwnProperty.call(options, 'sourceURL') | ||
? options.sourceURL.replace(/[\r\n]/g, ' ') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you coerce options.sourceURL
to a string. Something like (options.sourceURL + '').replace
would do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed :)
Coerce sourceURL to string
Awesome! Thank you so much @alexbrasetvik! Update: Published updated versions of |
Thanks for the quick turnaround! :) |
Prototype pollution is a common problem for Javascript applications.
This paper (PDF-link) is a reasonably comprehensive resource on the subject. It demonstrates that the problem is quite ubiquitous, and how it can turn into an unauthenticated RCE in Ghost, where the attack chain starts with a prototype pollution vulnerability in lodash.merge. Handlebars is used as the code execution gadget, but as Ghost also uses _.template it could have targeted that as well.
Lodash has had multiple prototype pollution vulnerabilities, including recently.
If
_.template
is ever invoked after the prototype has been polluted, an attacker can execute any Javascript, assourceURL
andvariable
are looked up via anoptions
object and injected into the Javascript that gets executed. If the caller is not passing those options (which is the most common usage), then the values from the potentially polluted prototype would be used instead. Here's the smallest possible POC:I initially reached out via npm security, and got the feedback that this is not considered an issue. (In the thread with NPM security I also provided examples of how to weaponise this against real applications instead of just the repl example. I can provide additional examples privately.)
I think it's worth fixing, as the fix is simple. Applications that are susceptible to prototype pollution will still need fixing, but at least the commonly used
_.template
shouldn't provide easy code execution.(I've signed the CLA.)