5

lodash has been reported to be vulnerable to the so called prototype pollution attack in versions up to (excluding) 4.17.5 See https://nvd.nist.gov/vuln/detail/CVE-2018-3721

Now lodash is the most depended upon package in the JavaScript eco system. The impact is that almost every at least mid-scale project has gazillions of different lodash dependencies and sub-dependencies in different versions included (run npm ls | grep lodash in a JS project of your choice to see for yourself). Now it will take lots and lots of effort and a lot of time to contribute to all of the open source projects that use lodash in version < 4.17.5.

Please explain, how can this vulnerability be used by attackers and what would be the right way to deal with this issue in a large scale frontend that has A LOT of production dependencies using lodash.

1 Answer 1

5

These are several questions cramped into one, so I will try to answer each one individually:

What is prototype pollution and how can it be used by an attacker?

I don't know how much JavaScript knowledge you have, so I will try to remain as generic as possible. JavaScript uses prototypes extensively to implement object inheritance. Basically, whatever you write into the prototype will be in the object instances. The Mozilla documentation will explain this far better than I could.

According to the report on HackerOne, if an attacker is able to insert their own data into lodash, they are able to add their own code to the object. The following PoC demonstrates this:

var _= require('lodash');
var malicious_payload = '{"__proto__":{"oops":"It works !"}}';

var a = {};
console.log("Before : " + a.oops);
_.merge({}, JSON.parse(malicious_payload));
console.log("After : " + a.oops);

If you run this code, you can see that a is modified, even if it is never written to directly.

So how does this affect your application? Well, this depends on your code. There is no "catch-all" answer. In some cases it can be a denial of service, in others a remote code execution.

For instance, one could replace the function toString() with a literal string. Attempting to call a string will result in an error, thus leading to a denial of service.

How can a large-scale application deal with a vulnerable package?

Either update your lodash version as soon as possible or apply a manual backport patch yourself. It might not be easy, but it's absolutely necessary.

If your application never processes any user input, then you may delay the update until you can, but it should be pretty high on your priority list.

6
  • Regarding the “How does this affect your application?” part: I know there is no “catch-all” answer, but could you add some examples? Many thanks! May 28, 2019 at 15:23
  • I added the example linked in the HackerOne report. But this is one of the issues where the effect is truly dependent on the individual codebase.
    – user163495
    May 28, 2019 at 15:54
  • 1
    @MechMK1 What do you mean by manual backport patch Jun 11, 2020 at 7:46
  • 1
    @PragamShrivastava Backporting means keeping a lower version number for compatibility reason, but "porting" a security patch "back" to the lower version number. That means even though the application uses a vulnerable version, the vulnerability itself is patched. Manual backporting means one would have to do this process themselves if no official backport is available.
    – user163495
    Jun 11, 2020 at 8:56
  • Which upgraded version of lodash solves this vulnerability ? Nov 11, 2021 at 9:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .