Version Details and Security Vulnerabilities

Affected versions of npm use predictable temporary file names during archive unpacking. If an attacker can create a symbolic link at the location of one of these temporary file names, the attacker can arbitrarily write to any file that the user which owns the npm process has permission to write to, potentially resulting in local privilege escalation.

Recommendation

Update to version 1.3.3 or later.

Affected versions of the npm package include the bearer token of the logged in user in every request made by the CLI, even if the request is not directed towards the user's active registry.

An attacker could create an HTTP server to collect tokens, and by various means including but not limited to install scripts, cause the npm CLI to make a request to that server, which would compromise the user's token.

This compromised token could be used to do anything that the user could do, including publishing new packages.

Recommendation

1. Update npm with npm install npm@latest -g
2. Revoke your Tokens
3. Enable Two-Factor Authentication

An issue was discovered in an npm 5.7.0 2018-02-21 pre-release (marked as "next: 5.7.0" and therefore automatically installed by an "npm upgrade -g npm" command, and also announced in the vendor's blog without mention of pre-release status). It might allow local users to bypass intended filesystem access restrictions because ownerships of /etc and /usr directories are being changed unexpectedly, related to a "correctMkdir" issue.

Versions of the npm CLI prior to 6.13.3 are vulnerable to an Arbitrary File Write. It fails to prevent access to folders outside of the intended node_modules folder through the bin field. A properly constructed entry in the package.json bin field would allow a package publisher to create files on a user's system when the package is installed. It is only possible to affect files that the user running npm install has access to and it is not possible to over write files that already exist on disk.

This behavior is still possible through install scripts. This vulnerability bypasses a user using the --ignore-scripts install option.

Recommendation

Upgrade to version 6.13.3 or later.

Versions of the npm CLI prior to 6.13.3 are vulnerable to a symlink reference outside of node_modules. It is possible for packages to create symlinks to files outside of thenode_modules folder through the bin field upon installation. A properly constructed entry in the package.json bin field would allow a package publisher to create a symlink pointing to arbitrary files on a user’s system when the package is installed. Only files accessible by the user running the npm install are affected.

This behavior is still possible through install scripts. This vulnerability bypasses a user using the --ignore-scripts install option.

Recommendation

Upgrade to version 6.13.3 or later.

Versions of the npm CLI prior to 6.13.4 are vulnerable to a Global node_modules Binary Overwrite. It fails to prevent existing globally-installed binaries to be overwritten by other package installations.

For example, if a package was installed globally and created a serve binary, any subsequent installs of packages that also create a serve binary would overwrite the first binary. This will not overwrite system binaries but only binaries put into the global node_modules directory.

This behavior is still allowed in local installations and also through install scripts. This vulnerability bypasses a user using the --ignore-scripts install option.

Recommendation

Upgrade to version 6.13.4 or later.

Versions of the npm CLI prior to 6.14.6 are vulnerable to an information exposure vulnerability through log files. The CLI supports URLs like <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>. The password value is not redacted and is printed to stdout and also to any generated log files.

Overview

The ini npm package before version 1.3.6 has a Prototype Pollution vulnerability.

If an attacker submits a malicious INI file to an application that parses it with ini.parse, they will pollute the prototype on the application. This can be exploited further depending on the context.

Patches

This has been patched in 1.3.6.

Steps to reproduce

payload.ini

[__proto__]
polluted = "polluted"

poc.js:

var fs = require('fs')
var ini = require('ini')

var parsed = ini.parse(fs.readFileSync('./payload.ini', 'utf-8'))
console.log(parsed)
console.log(parsed.__proto__)
console.log(polluted)

> node poc.js
{}
{ polluted: 'polluted' }
{ polluted: 'polluted' }
polluted

Versions of tar prior to 2.0.0 are affected by an arbitrary file write vulnerability. The vulnerability occurs because tar does not verify that extracted symbolic links to not resolve to targets outside of the extraction root directory.

Recommendation

Update to version 2.0.0 or later

Versions of tar prior to 4.4.2 for 4.x and 2.2.2 for 2.x are vulnerable to Arbitrary File Overwrite. Extracting tarballs containing a hardlink to a file that already exists in the system, and a file that matches the hardlink will overwrite the system's file with the contents of the extracted file.

Recommendation

For tar 4.x, upgrade to version 4.4.2 or later. For tar 2.x, upgrade to version 2.2.2 or later.

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to prevent extraction of absolute file paths by turning absolute paths into relative paths when the preservePaths flag is not set to true. This is achieved by stripping the absolute path root from any absolute file paths contained in a tar file. For example /home/user/.bashrc would turn into home/user/.bashrc.

This logic was insufficient when file paths contained repeated path roots such as ////home/user/.bashrc. node-tar would only strip a single path root from such paths. When given an absolute file path with repeating path roots, the resulting path (e.g. ///home/user/.bashrc) would still resolve to an absolute path, thus allowing arbitrary file creation and overwrite.

Patches

3.2.2 || 4.4.14 || 5.0.6 || 6.1.1

NOTE: an adjacent issue CVE-2021-32803 affects this release level. Please ensure you update to the latest patch levels that address CVE-2021-32803 as well if this adjacent issue affects your node-tar use case.

Workarounds

Users may work around this vulnerability without upgrading by creating a custom onentry method which sanitizes the entry.path or a filter method which removes entries with absolute paths.

const path = require('path')
const tar = require('tar')

tar.x({
  file: 'archive.tgz',
  // either add this function...
  onentry: (entry) => {
    if (path.isAbsolute(entry.path)) {
      entry.path = sanitizeAbsolutePathSomehow(entry.path)
      entry.absolute = path.resolve(entry.path)
    }
  },

  // or this one
  filter: (file, entry) => {
    if (path.isAbsolute(entry.path)) {
      return false
    } else {
      return true
    }
  }
})

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be outside of the extraction target directory is not extracted. This is, in part, accomplished by sanitizing absolute paths of entries within the archive, skipping archive entries that contain .. path portions, and resolving the sanitized paths against the extraction target directory.

This logic was insufficient on Windows systems when extracting tar files that contained a path that was not an absolute path, but specified a drive letter different from the extraction target, such as C:some\path. If the drive letter does not match the extraction target, for example D:\extraction\dir, then the result of path.resolve(extractionDirectory, entryPath) would resolve against the current working directory on the C: drive, rather than the extraction target directory.

Additionally, a .. portion of the path could occur immediately after the drive letter, such as C:../foo, and was not properly sanitized by the logic that checked for .. within the normalized and split portions of the path.

This only affects users of node-tar on Windows systems.

Patches

4.4.18 || 5.0.10 || 6.1.9

Workarounds

There is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does.

Users are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.

Fix

The fixed versions strip path roots from all paths prior to being resolved against the extraction target folder, even if such paths are not "absolute".

Additionally, a path starting with a drive letter and then two dots, like c:../, would bypass the check for .. path portions. This is checked properly in the patched versions.

Finally, a defense in depth check is added, such that if the entry.absolute is outside of the extraction taret, and we are not in preservePaths:true mode, a warning is raised on that entry, and it is skipped. Currently, it is believed that this check is redundant, but it did catch some oversights in development.

Description:

During some analysis today on npm's node-tar package I came across the folder creation process, Basicly if you provide node-tar with a path like this ./a/b/c/foo.txt it would create every folder and sub-folder here a, b and c until it reaches the last folder to create foo.txt, In-this case I noticed that there's no validation at all on the amount of folders being created, that said we're actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside

Steps To Reproduce:

You can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video

Proof Of Concept:

Here's a video show-casing the exploit:

Impact

Denial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources

Report resources

payload.txt archeive.tar.gz

Note

This report was originally reported to GitHub bug bounty program, they asked me to report it to you a month ago

A TOCTOU issue in the chownr package before 1.1.0 for Node.js 10.10 could allow a local attacker to trick it into descending into unintended directories via symlink attacks.

Versions of fstream prior to 1.0.12 are vulnerable to Arbitrary File Overwrite. Extracting tarballs containing a hardlink to a file that already exists in the system and a file that matches the hardlink will overwrite the system's file with the contents of the extracted file. The fstream.DirWriter() function is vulnerable.

Recommendation

Upgrade to version 1.0.12 or later.

Versions of npmconf before 2.1.3 allocate and write to disk uninitialized memory contents when a typed number is passed as input on Node.js 4.x.

Recommendation

Update to version 2.1.3 or later. Consider switching to another config storage mechanism, as npmconf is deprecated and should not be used.

Affected versions of request will disclose local system memory to remote systems in certain circumstances. When a multipart request is made, and the type of body is number, then a buffer of that size will be allocated and sent to the remote server as the body.

Proof of Concept

var request = require('request');
var http = require('http');

var serveFunction = function (req, res){
	req.on('data', function (data) {
            console.log(data)
        });
	res.end();
};
var server = http.createServer(serveFunction);
server.listen(8000);

request({
	method: "POST",
	uri: 'http://localhost:8000',
	multipart: [{body:500}]
},function(err,res,body){});

Recommendation

Update to version 2.68.0 or later

The request package through 2.88.2 for Node.js and the @cypress/request package prior to 3.0.0 allow a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP).

NOTE: The request package is no longer supported by the maintainer.

Affected versions of minimatch are vulnerable to regular expression denial of service attacks when user input is passed into the pattern argument of minimatch(path, pattern).

Proof of Concept

var minimatch = require(“minimatch”);

// utility function for generating long strings
var genstr = function (len, chr) {
  var result = “”;
  for (i=0; i<=len; i++) {
    result = result + chr;
  }
  return result;
}

var exploit = “[!” + genstr(1000000, “\\”) + “A”;

// minimatch exploit.
console.log(“starting minimatch”);
minimatch(“foo”, exploit);
console.log(“finishing minimatch”);

Recommendation

Update to version 3.0.2 or later.

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.

Versions 4.3.1 and earlier of semver are affected by a regular expression denial of service vulnerability when extremely long version strings are parsed.

Recommendation

Update to version 4.3.2 or later

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.