Security Vulnerabilities issue

[kundarsowjanya]

Hi,
I'm not using loader-utils directly in my package.json, but may be it has transitive dependency, and currently I'm using react-script v5,
but now I'm getting Security Vulnerabilities issue as

A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the resourcePath variable in interpolateName.js

and also I ran npm ls loader-utils, so the result is:

-- react-scripts@5.0.1 +-- @pmmmwh/react-refresh-webpack-plugin@0.5.8 | -- loader-utils@2.0.2
+-- @svgr/webpack@5.5.0
| -- loader-utils@2.0.2 deduped +-- babel-loader@8.2.5 | -- loader-utils@2.0.2 deduped
+-- file-loader@6.2.0
| -- loader-utils@2.0.2 deduped +-- react-dev-utils@12.0.1 | -- loader-utils@3.2.0
-- resolve-url-loader@4.0.0 +-- adjust-sourcemap-loader@4.0.0 | -- loader-utils@2.0.2 deduped
`-- loader-utils@2.0.2 deduped

could you please give me the suggestion how to fix this.

Thanks
Sowjanya

[alexander-akait]

loader-utils 2.0.0 is deprecated, please ask developers to update to v3 (even more, you don't need in most of cases loader-utils 2.0.0, because most of feature were moved to webpack itself)

[Donhv]

loader-utils 2.0.0 is deprecated, please ask developers to update to v3 (even more, you don't need in most of cases loader-utils 2.0.0, because most of feature were moved to webpack itself)

i see webpack have no plan to update loader-utils version. they still use v2.
i tried to force use v3 by resolutions but got error loaderUtils.getOptions

[kundarsowjanya]

Hi, even after using v3 still getting same error

A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 3.0.0 via the resourcePath variable in interpolateName.js

[jenilG]

We are also facing the same issue with 3.0.2

[alexander-akait]

I can't reproduce it using v3:

akait@akait-notebook:~/IdeaProjects/css-minimizer-webpack-plugin$ npm i loader-utils

added 1 package, and audited 1102 packages in 2s

156 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
akait@akait-notebook:~/projects/project$ npm audit
found 0 vulnerabilities
akait@akait-notebook:~/projects/project$ 

[alexander-akait]

And also I think there is a problem with a security tool, becaue I can't reproduce ReDos using https://github.com/webpack/loader-utils/blob/master/lib/interpolateName.js#L51

[alexander-akait]

So if somebody have an example of this exploit - PR welcome or write me on sheo13666q @ gmail.com, I am glad to fix it, but can't find a way how it is possible to use reproduce (that is why I think there is a problem with security tools)

[mdlkumaran]

Facing same issue

npm audit
(Use node --trace-warnings ... to show where the warning was created)

npm audit report

loader-utils ≤ 3.2.0
Severity: high
A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the resourcePath variable in interpolateName.js. - #211
fix available via npm audit fix --force
Will install @angular-devkit/build-angular@13.0.4, which is a breaking change
node_modules/loader-utils
@angular-devkit/build-angular >=13.1.0-next.0
Depends on vulnerable versions of loader-utils
node_modules/@angular-devkit/build-angular

2 high severity vulnerabilities

To address all issues (including breaking changes), run:
npm audit fix --force

[alexander-akait]

Please avoid duplicate, because it doesn't help, thank you

[v-pasha2]

is there any solution for this i am seeing this for version 3.2.0 as well ?

[angularDevEng]

any news?

[alexander-akait]

Please read my comments above, looks like it is false positive in security system, please report them

[JSMike]

Disregard, comment meant for #212

[alexander-akait]

@JSMike Thank for CVE-2022-37601, I will fix it, but the original issue about the security problem in interpolateName.js, and file and line is wrong

[JSMike]

@alexander-akait ah ok, sorry, I just assumed it was the same issue, I'll move my comments over to #212

[pratheeshp007]

@alexander-akait Is ReDoS possible on this line
https://github.com/webpack/loader-utils/blob/master/lib/interpolateName.js#L93

What if the line number was wrong in the report ?

[alexander-akait]

@pratheeshp007 Can you provide example of usage (exploit)? Because it is custom regexp and any utils which support RegExp as options can be affected this, I don't think it can be marked as exploit

[LucasLopesr]

is it a false positive?

[alexander-akait]

Sounds like yes, I tried to connect with administrators of security database, but no luck - no example of usage, no PoC and etc, the only found security problem was fixed in v2 here https://github.com/webpack/loader-utils/releases/tag/v2.0.3 (look at commits and you find where it was)

[jeran-urban]

Hello, left comments on other Issues, this Issue Looks Open, so here is the information for fixing both of the vulnerabilities shown in the OSS index:

The Vulnerabiliies:

• [CVE-2022-37603] A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the url variable in interpolateName.js.

  • Description: A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the url variable in interpolateName.js.

• [CVE-2022-37599] CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')

  • Description: A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the resourcePath variable in interpolateName.js.

The Problem

• The main issues around Regex DOS attacks is in badly formed queries that are not strict enough, and no exit condition involving a time limit for processing. If you ensure that the query is perfectly formed or at least add an exit condition based on a time limit (a few seconds) then this should resolve the issue. More information here: https://www.regular-expressions.info/redos.html#Handling%20Regexes%20Provided%20by%20The%20User. I believe this is still a legitimate vulnerability in v 3.x as well

The Fix

• multiple options listed under the CWE listing (https://cwe.mitre.org/data/definitions/1333.html, under Potential Mitigations section)
• update the regex to remove vulnerabilities
• add a timeout wrapper to prevent a malicious regex string from causing failures, dos, or resource overloads

ex of fix:

• timeout wrapper
  • https://www.npmjs.com/package/time-limited-regular-expressions
    • source code: https://github.com/apostrophecms/time-limited-regular-expressions/blob/main/index.js
  • https://www.josephkirwin.com/2016/03/12/nodejs_redos_mitigation/
  • (node.js documentation) https://nodejs.org/en/docs/guides/dont-block-the-event-loop/
• updated regex (mocha npm package update to remove same finding)
  • Code Change: https://github.com/mochajs/mocha/pull/4770/files
  • unit test: https://github.com/mochajs/mocha/pull/4917/files
• escape string wrapper
  • https://rules.sonarsource.com/javascript/tag/cwe/RSPEC-2631

I believe this would mitigate the findings

[jeran-urban]

Please let me know if I can be of help here, my own app would benefit from the updates as well for security issues that I am currently handling

[alexander-akait]

@jeran-urban Feel free to send a PR with fixes

[jmprentice]

Have you evaluated this line as the possible culprit?

loader-utils/lib/interpolateName.js

Line 79 in 52cd134

/\[(?:([^:\]]+):)?(?:hash|contenthash)(?::([a-z]+\d*))?(?::(\d+))?\]/gi,

I ran the Regex on that line through an online ReDoS checker and it came out vulnerable.

I believe this can be fixed by changing the Regex to /\[(?:([^\[:\]]+):)?(?:hash|contenthash)(?::([a-z]+\d*))?(?::(\d+))?\]/gi

The interpolateName.js tests pass with this change, but I don't know enough about what this section of your code is doing to be sure it wouldn't create any problems. If this seems like it will fix the ReDoS issue without breaking anything I can submit pull requests for the three versions. Our projects need versions 2.x and 1.x (loader-utils is a transitive dependency in multiple packages).

[alexander-akait]

@jmprentice Thank you, feel free to send a PR

[alexander-akait]

But not sure about GHSA-hhq3-ff78-jv3g, I really don't see any problems there

[alexander-akait]

Even more GHSA-hhq3-ff78-jv3g is refering on #211, but #211 is about another problem and it was fixed #217 and backported

[jmprentice]

My contributions are being rejected by EasyCLA, but you can see the change in the PR and should feel free to use it if it works.

[alexander-akait]

WIP, thank you anyway

[alexander-akait]

Fixed and released https://github.com/webpack/loader-utils/releases

[abhisheknigam87]

I can still find this warning with v3.2.1:
[CVE-2022-37603] A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the url variable in interpolateName.js.

[alexander-akait]

@abhisheknigam87 I think it is mistabe, becaise we fixed it 😕

[jeran-urban]

Sorry for not getting back sooner and thank you for getting to this so quickly. So, if I understand this correctly, here is some information:

• The CVE-2022-37603 finding has been resolved in version 3.2.1 (backported fixes available for versions 2.0.4 and 1.4.2 THANK YOU FOR THOSE!!!!)
  • OSSIndex shows the resultant fix: (old version 3.2.0 shows vulnerability): https://ossindex.sonatype.org/component/pkg:npm/loader-utils@3.2.0, (new version 3.2.1 no longer has that vulnerability): https://ossindex.sonatype.org/component/pkg:npm/loader-utils@3.2.1
  • Owasp Dependency Checker Shows this as no longer an issues as well.
  • Reporting Agencies that show vulnerability still exists: ( it may help to open and resolve [CVE-2022-37603]/ReDoS found in interpolateName.js #213 to show merged or some status that would satisfy the auto bot that opened it as that issue is watched by NVD it appears? not sure on that, but may help?)
    • Snyk: https://security.snyk.io/package/npm/loader-utils
    • NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-37603
    • CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37603
  • This issue should no longer be showing as a problem for the versions listed above. To help expedite this, I have sent requests via tickets to NVD/NIST, CVE, and Snyk to update the configuration strings/reports/etc to show the version that has the fix and stop reporting false positives (I will update here once I get responses from those entities). That may take time (and depending on what software you are using to run scans, you may still see this is an issue). In the meantime. The content provided here should be enough to verify that the issue is a false positive if you are on the correct version.

There is still an issue for https://ossindex.sonatype.org/vulnerability/CVE-2022-37599?component-type=npm&component-name=loader-utils that will need to be addressed though.

Hopefully this helps and I will look at getting a PR for CVE-2022-37599 asap, but may be awhile until I have the free time needed.

[jeran-urban]

so I believe changing line 83

from this:
directory = resourcePath.replace(/\\/g, '/').replace(/\.\.(\/)?/g, '_$1');

to this:
directory = resourcePath.replaceAll(/\\/g, '/').replaceAll(/\.\.(\/)?/g, '_$1');

should fix the issue:
Ex of difference between replace and replace all and how the call to the Regex constructor behind the scenes on replace can be dangerous: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll#description

I am not positive that this will resolve the issue, but it should allow for a safer open ended regex run against an unknown string with the built in processing of replaceAll at least. If not, I would look at adding a timer wrapper around the evaluation to fail if it takes longer than x seconds as a catch all.

PR #227 submitted.

[jeran-urban]

to update the thread, on PR #227, the PR has been closed given the following information:

from looking at the various tickets, issues, and vulnerabilities, there are 3 vulnerabilities that have been discussed:

• [CVE-2022-37601] - an older critical issue that was addressed in 2.0.3 and backported to 1.4.1 as well (addressed directly by fix: Resolve potential prototype polution exploit #217)
• [CVE-2022-37603] - a more recent high finding that was just addressed in 3.2.1 and backported to 2.0.4 and 1.4.2 (quoted as a problem against the url variable in this file) (addressed directly by fix: ReDoS problem #224)

lastly

• [CVE-2022-37599] - a more recent high finding that has not yet been addressed in some systems (quoted as a problem against the resourcePath variable in this file) (no direct fix provided).

I did not see an issue with the current code either as there are no wildcard characters that are exploitable and this regex itself is simple and has no known redos issues currently either (in reference to line 83 as defined in the finding). But given that as of the day I posted this PR, OSSIndex still showed this as a valid finding, as was Snyk, NVD, etc. and as of yesterday at 11:22am cst, multiple security scans were still showing this as a finding as well.

Given that, there is a difference behind the scenes for replace vs. replace all, that I was hoping this would address, and would address the remaining open finding from the various security agencies that were still reporting this as an active issue.

But as of now, the scans we are running show this package as compliant and the finding appears to be considered addressed by OSS (not the other agencies yet). I already do have tickets open to Snyk, NVD and Mitre for the CVE to update these to show the issues as fixed, and have added this CVE to those tickets, not just the CVE-2022-37603 issue.

Given all of that, as of now, this PR does not seem to be needed and there does not appear to be an issue with the code, as the parts replaceAll targets as issues for replace are not being used here.

It may take time for the various security tools to update and not show these findings as valid, (and correct me if I am wrong @alexander-akait ), but as long as you are on the latest versions(1.4.2, 2.0.4, 3.2.1), you should be able to site this issue as verification that these are false positives. Thank you loader-utils team for addressing this so quickly! my team appreciates it a lot!

[jeran-urban]

updates with fixes posted to github advisory via PRs listed above, once accepted, those should show the recommended resolution on npm audit commands from now on

[jeran-urban]

Snyk has updated their documentation for affected versions, closed the tickets, and is now reporting no vulnerabilities for versions 1.4.2, 2.0.4, and 3.2.1!

[sjorsverhoef]

Nice work!

[LucasLopesr]

nice work guys!

[jeran-urban]

the github advisory entries have been updated and now npm audit will show the relevant errors, and there is an auto fix available that npm audit fix will resolve

[jeran-urban]

NIST's NVD is showing as fixed for https://nvd.nist.gov/vuln/detail/CVE-2022-37601 and https://nvd.nist.gov/vuln/detail/CVE-2022-37603, still working on https://nvd.nist.gov/vuln/detail/CVE-2022-37599.

[jeran-urban]

https://nvd.nist.gov/vuln/detail/CVE-2022-37599 has now been updated as well.

With these updates, Sonatype's OSS INDEX, NIST's NVD, NPM Github Advisory, and Snyk's Reports have all been updated and all known vulnerabilities have been handled and backported for all major versions. I think this issue should be good to consider closed. I still have pending CVEs to be updated, but those normally take awhile.

For anyone tracking this issue that still is showing vulnerabilities in their scans, please give it another 24 hours for the agencies to push to feeds, and other agencies to update from those feeds to rerun your scans, after that, you should no longer see these issues as long as you are on the correct versions.

Thank you again to the loader-utils team and please let me know if I can be of any help in future.

[jeran-urban]

as an aside, @alexander-akait, I left a comment regarding the regex in #227, may be able to simplify or refactor the regex to target differently for the replace functionality