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.

Anders
  • 64,406
  • 24
  • 178
  • 215
borisdiakur
  • 153
  • 1
  • 5

1 Answers1

4

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.

  • 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! – borisdiakur May 28 '19 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. –  May 28 '19 at 15:54
  • @MechMK1 What do you mean by manual backport patch – Pragam Shrivastava Jun 11 '20 at 07:46
  • @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. –  Jun 11 '20 at 08:56
  • Which upgraded version of lodash solves this vulnerability ? – Kartik Bhatia Nov 11 '21 at 09:12
  • @KartikBhatia 4.17.21 is the latest version and the only one without known vulnerabilities. –  Nov 11 '21 at 13:16