Lodash: Understanding the recent vulnerability and how we can rally behind packages

We all hate it when we get an email from one of our CI/CLI tools complaining about a new vulnerability in one of our dependencies, and if there’s no easy patch available, some of us rush to GitHub and write a passive-aggressive GitHub Issue asking a maintainer of the package to prepare a fix, to provide timelines, and to keep communications lines open on the issue. Maintainers already have a lot on their plates, especially if their package becomes mainstream and is utilised by sometimes millions of developers worldwide, like Lodash.

Lodash is a JavaScript library that provides functions for common programming tasks. It is the #1 most used package on NPM, and is being downloaded 34m+ times a week! We use it at huntr.dev, so when we saw that it had a vulnerability, we kept a keen eye and followed the process that ensued.

On April 30th, a Prototype Pollution vulnerability was identified in the most depended upon package on NPM; Lodash. If this is the first time finding this out, don’t worry, a fix has been developed and merged into the repo — so you are safe (for now).

In this post, we will dive into the detail: the disclosure, the fix and then discuss where we as a community could have done better!

On the 30th April, an issue was opened on the Lodash repository by @nickrobson stating that he had found a prototype pollution vulnerability in lodash.js. The next day he had opened a pull request with a fix for the vulnerability. However, the maintainer only accepted the pull request almost 2 months later.

So why did it take so long for the maintainer to feel comfortable merging the pull request? Before we go into the potential reasons, let’s take a look at the vulnerable code and see how it could have affected the users of Lodash (shoutout to our #1 huntr @MufeedVH for the writeup):

Lodash versions prior to 4.17.19 are vulnerable to a Prototype Pollution (CVE-2020–8203). The function zipObjectDeep() allows a malicious user to modify the prototype of an Object if the property identifiers are user-supplied. To be affected by this issue, developers would have to be zipping objects based upon user-provided property arrays.

This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under certain circumstances.

The vulnerability arises when we give a maliciously crafted object to the zipObjectDeep() function in Lodash.

The Vulnerable Code:

When we call the function zipObjectDeep(), it passes the input object and an assigned function to baseZipObject() function, which contains the code:

The assigned function given to baseZipObject() function is baseSet which is the function modifying the prototype. This function doesn't have any validation of the input object, making it possible to inject a prototype and causing a Prototype Pollution Attack.

This is how the vulnerable function baseSet() was implemented:

The input object is not properly validated and is then used to assign values and keys. If we give a maliciously crafted object with a prototype, we can pollute the object and it can lead to Denial of Service or Code Execution.

As the function didn’t have any validation, just passing a basic prototype is enough to demonstrate/exploit the vulnerability.

Proof of Concept:

Let’s give a maliciously crafted prototype as the input to the function zipObjectDeep().

The above-crafted code shows how with a user-provided input, we can manipulate the prototype of Object and inject a fraudulent isAdmin flag. This can be dangerous in many ways, bypassing AuthN/AuthO implementations, executing arbitrary code and other creative ways that a hacker could come up with.

Now before reading on, we shouldn’t look to point the finger, especially not the maintainers of Lodash. If you look back at the commit logs, they have been updating, fixing bugs, and maintaining the package since the beginning.

So here’s the controversial statement (if you want to weigh in and give your opinion on this please do in the comments). On the 1st May @jdalton moved the issue to a separate thread and responded with:

He then shut the thread to the public allowing only maintainers to comment. Whether he could have said it better is neither here nor there, but shortly after this, many of Lodashs’ users were posting on the original issue asking for one of the fixes to be merged:

It’s also important to note here that it’s unclear that of the 117,952 projects (as @martin-walsh highlighted), how many of these do depend-upon user provided property arrays when interacting with zipObjectDeep and what can these projects do, given the locking of the thread and the delaying of the PR acceptance - what if @jdalton had serious concerns with the proposed PR?

Why was it not merged?

Before going into the technicality of the fix itself, let’s assume it was sufficient, so why was it not merged? Here are a few reasons we’ve seen in similar situations:

1. The maintainer did not have the time to check the fix

The maintainer is on holidayHas just had a family grievanceIs simply taking a break

2. Maintainers aren’t security-minded

Maintainers who aren’t well versed in security are likely not well equipped to check and remediate these issues

3. No incentive for the maintainer to act

The maintainer has a tech roadmap that he is looking to follow, he is deep into his sprint and is focused on developing new features, and so, this isn’t a priority

4. ‘Too many cooks spoil the broth’

The fix was written by the original discloser, but shortly after, Snyk got involved and developed a different fix, then a report was published on Hackerone, and even SourceClear and of-course the NPM advisory team were involved.

Why we shouldn’t complain

Your first reaction may be ‘wow! how could a maintainer ignore this?!’, ‘how could he say that?!’ but in truth, we should not be complaining… Lodash is free — it’s maintained by contributors for free and utilised by millions of developers for free — why should the maintainer act, what’s in it for them?

If you are a developer and you are reading this, what is currently on your desk, in your pipeline, the problem you have spent the past 3 hours trying to fix, and then imagine someone comes over, taps you on the shoulder and says, “stop what your doing” we have another problem thats more important. Now imagine that person hasn’t been involved in the development of the package up to now… Would you stop what you were doing and do what they ask of you?

We need a way to take some of that burden off of their shoulders, and help them as much we can to get security issues fixed as quickly as possible — this is where huntr.dev comes in (which we will talk about briefly later).

To fix Prototype Pollution Attacks, there are multiple ways. We can fix it by freezing the Object with the JavaScript ES5 function Object.freeze() or by defining a null Object Object.create(null). The other way to fix this vulnerability is to validate the input to check for added prototypes. The implementation can vary according to different use cases.

(To find out more about Prototype Pollution Attacks and it’s mitigations, check out this paper: Prototype pollution attack in NodeJS application)

Lodash fixed this issue by validating the input Object to check for prototypes. Here is the fixed code:

[Reference: Fix Commit]

We can see that the patch on the function baseSet(), has implemented a simple validation to check for prototype keywords (__proto__, constructor and prototype), where if it exists, the function returns the object without modifying it, thus fixing the Prototype Pollution Vulnerability.

So if the aim is to reduce the time from point of disclosure to point of the merge, is there a way we as a community can help?

Crowdsourced security for open source. We have seen the open source vulnerability landscape increase drastically over the past few years, and it looks like in a lot of areas it is only going up. We aim to help maintainers mitigate some of these issues, giving both them and there users peace of mind knowing that there is a body that is not only incentivising security disclosures, but also the remediation of the vulnerability and even the acceptance of the pull request.

By leveraging community sheriffs with backgrounds in security, we are constantly reviewing disclosures across the whole open source eco-system, collating all of the information, developing a sufficient fix, and providing it to the package owners in an easy to understand way.

When we find something in a package you are a maintainer of, we will notify you, and open up a bounty to get a fix created as soon as possible! Usually, these programs ask you to sponsor, give up some money, but what we ask is for you to communicate, when you see us pop up on your repository, if you disagree with our findings, let us know, let’s discuss it in the open, so everyone can chip in. And if you are happy with a fix, all we ask is you don’t leave your users waiting and accept the pull request as early as possible!

The ultimate aim is to reduce the average time it takes to fix vulnerabilities across the whole open source ecosystem. It’s a mammoth task, but one we are willing to take on, and will not give up until it is beaten.

Contact

Want to be part of the journey? Sign up at huntr.dev, find and fix vulnerabilities in open source, and build your security profile.

And if your a maintainer who could use some help with outstanding vulnerabilities, then send an email to info@huntr.dev and we will rally the community to try and create a fix!

References

https://nvd.nist.gov/vuln/detail/CVE-2020-8203https://hackerone.com/reports/712065