[Med] Snyk: Denial of Service (DoS) (due 6/2/19)

[fec-jli]

package.json 2 medium
Denial of Service (DoS) --MEDIUM SEVERITY
Vulnerable module: mem
Introduced through: npm@6.8.0
https://app.snyk.io/vuln/npm:mem:20180117

[jason-upchurch]

Denial of Service (DoS)

Vulnerable module: mem
Introduced through: npm@6.8.0

Detailed paths and remediation

• Introduced through: fec-cms@1.0.0 › npm@6.8.0 › libnpx@10.2.0 › yargs@11.0.0 › os-locale@2.1.0 › mem@1.1.0
  Remediation: No remediation path available.
  Vulnerable functions
  index.module.exports.memoized()

Overview

mem is an optimization used to speed up consecutive function calls by caching the result of calls with identical input.

Affected versions of this package are vulnerable to Denial of Service (DoS). Old results were deleted from the cache and could cause a memory leak.

details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade mem to version 4.0.0 or higher.

[rfultz]

Current status:
BLOCKED BY zkat/npx#206

I'm watching libnpx for new releases.

Updating to mem@^4.0.0 is easier said than done.

os-locale had an issue for this (sindresorhus/os-locale#32) but there was a breaking change in mem@3 which would require os-locale to jump to 3 instead of a 2.1.1. An os-locale 3 would require an update from yargs.

yargs #1209 says that yargs 12.0.2 passes the Snyk test.

But libnpx@10.2.0 wants yargs@^11.0.0. There's an issue to address this, but it hasn't received any attention. There was a previous ticket for other dependencies but it hasn't cleared this Snyk alert.

npm 6.9.0 wants libnpx@^10.2.0. If libnpx stays at 10.* we should be ready when libnpx is updated. Otherwise, we may need an update from npm to allow a currently-non-existent libnpx 11.

[dorothyyeager]

Still blocked. Moving to 9.2

[dorothyyeager]

Moving to 9.4; PR needs review.