Vulnerability in node-forge dependency (CVE-2020-7720)

[stanlemon]

🐛 bug report

CVE-2020-7720

The package node-forge before 0.10.0 is vulnerable to Prototype Pollution via the util.setPath function. Note: Version 0.10.0 is a breaking change removing the vulnerable functions.

🎛 Configuration (.babelrc, package.json, cli command)

Include parcel, node-forge is a dependency and is vulnerable.

🤔 Expected Behavior

Install parcel with no vulnerabilities.

😯 Current Behavior

Install parcel with vulnerability.

💁 Possible Solution

Upgrade node-forge.

🔦 Context

Insecure application.

💻 Code Sample

Use the amazing parcel!

🌍 Your Environment

Software	Version(s)
Parcel	1.12.4
Node	*
npm/Yarn	*
Operating System	*

[DeMoorJasper]

This isn't really a security vulnerability that applies to Parcel, you can look at the changelog of node-forge where they mention this vulnerability applies to utils that weren't even being used in node-forge and neither did we in Parcel: https://github.com/digitalbazaar/forge/blob/master/CHANGELOG.md#0100---2020-09-01

To get rid of the useless warning I created a PR to fix this in Parcel 2 #5149 but unfortunately we don't publish new v1 releases

[zawys]

Dependabot notifies:

Cannot be solved by yarn upgrade.

[Flupster]

Are we going to leave node-forge 0.7.6 in the 1.x version?

npm i parcel-bundler; npm ls node-forge

/home/flupster/test
└─┬ parcel-bundler@1.12.4
  └── node-forge@0.7.6 

[MrBrownser]

I know the exposed method is not applied in Parcel, but being this a security topic I think it should be fixed in actual 1.X version.
In my case this is stopping my build pipeline (shared with other Node applications) where we do have an npm audit step checking all "high and above" vulnerabilities, and I bet I won't be the only one.

I could ship a PR if this could help, just let me know.

[stanlemon]

@MrBrownser a PR was previously submitted, see #5146 but @DeMoorJasper closed it.

Part of the issue here is the vulnerable code is available to a project using parcel, it's not just a matter of parcel not using the vulnerable code in question. Any enterprise software company has scanning software (GitHub, Snyk, etc.) and this vulnerability does create risk that has to be explained or mitigated. It is often much more challenging to explain why a certain amount of risk should be accepted when the alternative is switching to something else. The alternative of just using 2.0 isn't really viable either as many organizations limit using beta software because it's generally considered to not be production-ready.

I'm not looking to create issues with the maintainers of parcel, the software has been good to me and helped me move fast on a number of projects. At the same time the unwillingness to look at this is disheartening and discouraging.

[DeMoorJasper]

This is not an actual security issue it isn't even a real security issue in node-forge, these util functions weren't used by node-forge nor Parcel so it's a false positive by the npm security team, if you want to blame anyone blame their poor security audit tools (this issue should've been flagged low severity at most). This doesn't create any risk for any organisation, although warnings don't look good and many people won't bother to actually look up a security issue and just trust npm completely.

I've started a discussion about this internally, if this gets through we'll make a patch release just to get rid of the warning...

[danielrbradley]

Just in case anyone's looking for a workaround - I just added a manual resolution for the sub-package using the 'resolutions' feature in the package.json:

{
 ...
  "resolutions": {
    "node-forge": "0.10.0"
  }
}

[woutervanbakel]

@DeMoorJasper what is the reason of not publishing a patch on v1 anymore? Vulnerability to Parcel or not this blocks the CI of many happy Parcel users on the audit step. As there is also still no "overrides" function in npm there is not really a neat workaround.

[DeMoorJasper]

@woutervanbakel I think the main reason is that it is not easy to publish a new version for Parcel 1 as testing and CI is kind of messed up for master branch.

Besides that Devon is also the only person who can publish the packages... Like I said I brought this up internally without any response so can't do much more than that

[woutervanbakel]

@DeMoorJasper The publishing of packages part I get. It is of-course a pity that only one person can publish ;-)

But in terms of messing up the master branch, there are tags used in this repository? Or at least the commit hash of the published version is known right?

[DeMoorJasper]

@woutervanbakel yeah it's definitely possible just kind of complicated. Would fix this if I could

[phocks]

Just in case anyone's looking for a workaround - I just added a manual resolution for the sub-package using the 'resolutions' feature in the package.json:

{
 ...
  "resolutions": {
    "node-forge": "0.10.0"
  }
}

Thanks. Also needed this in my "scripts":

"scripts": {
  "preinstall": "npx npm-force-resolutions"
}

(from https://www.npmjs.com/package/npm-force-resolutions)

[wis]

@phocks I use yarn, I didn't need to do this.
Jasper I agree with you, but GitHub repo vulnerable dependencies warnings are annoying so you need to fix them even if you're unaffected.