CVE-2022-25883 and CVE-2022-3517 with respect to `mlir/utils/vscode/package-lock.json`

[rolfmorel]

Summary

Automated checks by Wiz flag up that packages semver and minimatch have outdated versions in the package-lock.json file for the MLIR VSCode extension which lives inside llvm-project. These outdated versions have known CVEs which are classified as "high severity" according to the automated emails we are receiving. Our internal security system considers this a serious enough issue to threaten to disconnect the affected machine from the company network.

Note that normal llvm-project builds will not involve building the VSCode extension: Wiz is complaining that these (versions of the) packages are even mentioned in the lock file. However, this does mean that the distributed version of the VSCode extension (presumably) comes with the affected package versions.

Details

Both CVEs concern Regular Expression Denial of Service (ReDoS) vulnerabilities.

Summaries according to the National Vulnerability Database:

CVE-2022-3517:

A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.

CVE-2022-25883:

Versions of the package semver before 7.5.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

Here are the respective summaries by Wiz:

CVE-2022-3517:

The library minimatch version 3.0.4 was detected in NPM library manager located at /scratch/tpp-llvm-tar/llvm-project-faf5d747f174cc9d714839f0d3bce1a783eac2ac/mlir/utils/vscode/package-lock.json on line 1198 and is vulnerable to CVE-2022-3517, which exists in versions < 3.0.5.

The vulnerability was found in the Github Security Advisory with vendor severity: High (NVD severity: High).

The vulnerability can be remediated by updating the library to version 3.0.5 or higher, using npm update minimatch.

CVE-2022-25883:

The library semver version 7.3.7 was detected in NPM library manager located at /scratch/tpp-llvm-tar/llvm-project-faf5d747f174cc9d714839f0d3bce1a783eac2ac/mlir/utils/vscode/package-lock.json on line 1905 and is vulnerable to CVE-2022-25883, which exists in versions >= 7.0.0, < 7.5.2.

The vulnerability was found in the Github Security Advisory with vendor severity: High (NVD severity: High).

The vulnerability can be remediated by updating the library to version 7.5.2 or higher, using npm update semver.

PoC

All we do is download a checkout of a recent llvm-project version (couple days old as of the creation of the report), in our case as a tar, and unpack it. Our subsequent build does not involve the MLIR VSCode extension, i.e. we do not build it.

As far as we understand, Wiz performs an automated sweep in the background over the checked out files and complains about the contents of mlir/utils/vscode/package-lock.json even if the system in question does not have npm installed and the files are not used for any build/by any executable.

Manually removing the file from all checkouts seems to have appeased at least one of the vulnerability checkers. We expect that when we obtain a new checkout - and do not delete the lock file - we do get new warnings and machine disconnection threats.

Impact

Potentially it affects the MLIR VSCode extension that is distributed in the VSCode extension "store". As the CVEs concern Regex DOS and VSCode (mostly) runs locally and without arbitrary network clients, the potential for actual abuse seems low.

Security vulnerability report

The above was reported as a security vulnerability first (GHSA-g72r-487m-m6hh). That got closed with a request to make it a normal issue. Here we are.

[llvmbot]

@llvm/issue-subscribers-mlir

Author: Rolf Morel (rolfmorel)

### Summary Automated checks by Wiz flag up that packages `semver` and `minimatch` have outdated versions in the `package-lock.json` file for the MLIR VSCode extension which lives inside `llvm-project`. These outdated versions have known CVEs which are classified as "high severity" according to the automated emails we are receiving. Our internal security system considers this a serious enough issue to threaten to disconnect the affected machine from the company network.

Note that normal llvm-project builds will not involve building the VSCode extension: Wiz is complaining that these (versions of the) packages are even mentioned in the lock file. However, this does mean that the distributed version of the VSCode extension (presumably) comes with the affected package versions.

Details

Both CVEs concern Regular Expression Denial of Service (ReDoS) vulnerabilities.

Summaries according to the National Vulnerability Database:

CVE-2022-3517:
> A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.

CVE-2022-25883:
> Versions of the package semver before 7.5.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

Here are the respective summaries by Wiz:

CVE-2022-3517:
> The library minimatch version 3.0.4 was detected in NPM library manager located at /scratch/tpp-llvm-tar/llvm-project-faf5d747f174cc9d714839f0d3bce1a783eac2ac/mlir/utils/vscode/package-lock.json on line 1198 and is vulnerable to CVE-2022-3517, which exists in versions < 3.0.5.
>
> The vulnerability was found in the Github Security Advisory with vendor severity: High (NVD severity: High).
>
> The vulnerability can be remediated by updating the library to version 3.0.5 or higher, using npm update minimatch.

CVE-2022-25883:
> The library semver version 7.3.7 was detected in NPM library manager located at /scratch/tpp-llvm-tar/llvm-project-faf5d747f174cc9d714839f0d3bce1a783eac2ac/mlir/utils/vscode/package-lock.json on line 1905 and is vulnerable to CVE-2022-25883, which exists in versions >= 7.0.0, < 7.5.2.
>
> The vulnerability was found in the Github Security Advisory with vendor severity: High (NVD severity: High).
>
> The vulnerability can be remediated by updating the library to version 7.5.2 or higher, using npm update semver.

PoC

All we do is download a checkout of a recent llvm-project version (couple days old as of the creation of the report), in our case as a tar, and unpack it. Our subsequent build does not involve the MLIR VSCode extension, i.e. we do not build it.

As far as we understand, Wiz performs an automated sweep in the background over the checked out files and complains about the contents of mlir/utils/vscode/package-lock.json even if the system in question does not have npm installed and the files are not used for any build/by any executable.

Manually removing the file from all checkouts seems to have appeased at least one of the vulnerability checkers. We expect that when we obtain a new checkout - and do not delete the lock file - we do get new warnings and machine disconnection threats.

Impact

Potentially it affects the MLIR VSCode extension that is distributed in the VSCode extension "store". As the CVEs concern Regex DOS and VSCode (mostly) runs locally and without arbitrary network clients, the potential for actual abuse seems low.

Security vulnerability report

The above was reported as a security vulnerability first (GHSA-g72r-487m-m6hh). That got closed with a request to make it a normal issue. Here we are.

[rolfmorel]

After updating the packages with npm - as instructed in the above messages - I get an error when trying to compile the extension:

$ tsc -p .
node_modules/@types/node/globals.d.ts:126:13 - error TS2403: Subsequent variable declarations must have the same type.  Variable 'AbortSignal' must be of type '{ new (): AbortSignal; prototype: AbortSignal; abort(reason?: any): AbortSignal; any(signals: AbortSignal[]): AbortSignal; timeout(milliseconds: number): AbortSignal; }', but here has type '{ new (): AbortSignal; prototype: AbortSignal; abort(reason?: any): AbortSignal; timeout(milliseconds: number): AbortSignal; }'.

126 declare var AbortSignal: {
                ~~~~~~~~~~~

  ../../../../../../../../../usr/lib/node_modules/typescript/lib/lib.dom.d.ts:2606:13
    2606 declare var AbortSignal: {
                     ~~~~~~~~~~~
    'AbortSignal' was also declared here.


Found 1 error in node_modules/@types/node/globals.d.ts:126

I tried updating the types package as well but couldn't get this error to go away.

[rengolin]

In addition to fixing the version, I'd recommend we don't install those files unless the VSCode module is built, to avoid false dependency issues.

[rolfmorel]

As far as I understand the issue is that this lock file is there even just checked-in in the repository. When you do a checkout you already get the lock file as-is and automated scanners start shouting about it. Even if it is not used by you/your machine in any build or any install.

[rengolin]

@kbeyls What's the process here?

[kbeyls]

@kbeyls What's the process here?

AFAIK, there is no special process here.
This is a publicly known issue, so falls outside the scope of the LLVM Security Response Group, which focusses on coordinated disclosure of not-yet-publicly-known security issues. This can be fixed through the normal "bug found, someone with enough motivation to fix it fixes it through the normal PR process"-process.

I guess if we'd enable github dependabot, it would probably highlight some of the dependencies in the LLVM repo that may have known CVEs. FWIW, the LNT repo has this enabled, and it shows these warnings: https://github.com/llvm/llvm-lnt/security/dependabot. For LNT, my understanding is that just updating to newer versions of dependencies won't work, as it breaks LNT. Extra, probably significant, work would be needed to be able to update the dependencies. For a long time, no-one has shown the motivation to go and spend the effort to be able to update these out-dated dependencies in LNT.

[rengolin]

I guess if the VSCode extension continues creating these problems, the safest thing is to keep it out of the monorepo. For now, we're fixing by bumping the version (VSCode people are responsible for making sure that works).