https://nodesecurity.io/advisories/130

[blaggacao]

https://nodesecurity.io/advisories/130

[blaggacao]

is this a wontfix for a security issue?

[blaggacao]

Or do you hereby request further explanation?

[defunctzombie]

Would be nice to get a PR or more explanation or if this is even an issue for this module; just saying "security issue" doesn't instantly make it a fire that needs putting out. Ideally some sort of proof of issue would be shown against this module otherwise this is just drive-by security on your part where you found some notice on a website about a module in our dependency tree and didn't bother giving any additional details or checking if it is actually a concern.

[blaggacao]

Alright, sorry for that.
I'm not able to further investigate or judge, as I don't know the implementation details of localtunnel nor the referenced library.

As this error showed up during installation, I was assuming that linked site is well known common ground in the node world and that my observations would be imminent to posting just the link.

---

What I can tell:

• tough-cookie seems to be a dependency of localtunnel
• tough-cookie is tagged at @2.2.2
• the linked site supports a possibility of ReDoS via long string of semicolons
• This issue was reported for >=0.9.7 through <=2.2.2 on July 22nd, 2016 by David Kirchner
• It's CVSS score is high at 7.5
  From the description:

  Versions 0.9.7 through 2.2.2 contain a vulnerable regular expression that, under certain conditions involving long strings of semicolons in the "Set-Cookie" header, causes the event loop to block for excessive amounts of time.

Version bump to 2.3.0 is recommended.

In the case that localtunnel is compatible with 2.3.0, as to my (humild) judgment, bumping the version would be a no brainer and does not require further argumentative support.

npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing Set-Cookie https://nodesecurity.io/advisories/130

[defunctzombie]

Thank you for following up. We don't directly depend on that module so it
must be a dependency of some other dependency. Do you know what that is and
which of our dependencies would need to be updated?

On Saturday, August 6, 2016, David Arnold notifications@github.com wrote:

Alright, sorry for that.
I'm not able to further investigate or judge, as I don't know the
implementation details of localtunnel nor the referenced library.

As this error showed up during installation, I was assuming that linked
site is well known common ground in the node world and that my observations

would be imminent to posting just the link.

What I can tell:

• tough-cookie seems to be a dependency of localtunnel
• tough-cookie is tagged at @2.2.2
• the linked site supports a possibility of ReDoS via long string of
  semicolons
• This issue was reported for >=0.9.7 through <=2.2.2 on July 22nd,
  2016 by David Kirchner
• It's CVSS score is high at 7.5 From the description: >Versions 0.9.7
  through 2.2.2 contain a vulnerable regular expression that, under certain
  conditions involving long strings of semicolons in the "Set-Cookie" header,
  causes the event loop to block for excessive amounts of time.

Version bump to 2.3.0 is recommended.

In the case that localtunnel is compatible with 2.3.0, as to my (humild)
judgment, bumping the version would be a no brainer and does not require
further argumentative support.

npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing
Set-Cookie https://nodesecurity.io/advisories/130

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#136 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFLONK7lFdrXEz9VpGfeuz__uII64MIks5qdMgagaJpZM4JeTwV
.

[blaggacao]

npm isn't that bad 😄 - I wasn't used to that usability levels...

It's the request@2.65.0

`-- localtunnel@1.8.1
  +-- debug@2.2.0
  | `-- ms@0.7.1
  +-- openurl@1.1.0
  +-- request@2.65.0
  | +-- aws-sign2@0.6.0
  | +-- bl@1.0.3
  | | `-- readable-stream@2.0.6
  | |   +-- core-util-is@1.0.2
  | |   +-- inherits@2.0.1
  | |   +-- isarray@1.0.0
  | |   +-- process-nextick-args@1.0.7
  | |   +-- string_decoder@0.10.31
  | |   `-- util-deprecate@1.0.2
  | +-- caseless@0.11.0
  | +-- combined-stream@1.0.5
  | | `-- delayed-stream@1.0.0
  | +-- extend@3.0.0
  | +-- forever-agent@0.6.1
  | +-- form-data@1.0.0-rc4
  | | `-- async@1.5.2
  | +-- har-validator@2.0.6
  | | +-- chalk@1.1.3
  | | | +-- ansi-styles@2.2.1
  | | | +-- escape-string-regexp@1.0.5
  | | | +-- has-ansi@2.0.0
  | | | `-- supports-color@2.0.0
  | | +-- commander@2.9.0
  | | | `-- graceful-readlink@1.0.1
  | | +-- is-my-json-valid@2.13.1
  | | | +-- generate-function@2.0.0
  | | | +-- generate-object-property@1.2.0
  | | | | `-- is-property@1.0.2
  | | | +-- jsonpointer@2.0.0
  | | | `-- xtend@4.0.1
  | | `-- pinkie-promise@2.0.1
  | |   `-- pinkie@2.0.4
  | +-- hawk@3.1.3
  | | +-- boom@2.10.1
  | | +-- cryptiles@2.0.5
  | | +-- hoek@2.16.3
  | | `-- sntp@1.0.9
  | +-- http-signature@0.11.0
  | | +-- asn1@0.1.11
  | | +-- assert-plus@0.1.5
  | | `-- ctype@0.5.3
  | +-- isstream@0.1.2
  | +-- json-stringify-safe@5.0.1
  | +-- mime-types@2.1.11
  | | `-- mime-db@1.23.0
  | +-- node-uuid@1.4.7
  | +-- oauth-sign@0.8.2
  | +-- qs@5.2.1
  | +-- stringstream@0.0.5
  | +-- tough-cookie@2.2.2
  | `-- tunnel-agent@0.4.3
  `-- yargs@3.29.0
    +-- camelcase@1.2.1
    +-- cliui@3.2.0
    | +-- string-width@1.0.1
    | | +-- code-point-at@1.0.0
    | | | `-- number-is-nan@1.0.0
    | | `-- is-fullwidth-code-point@1.0.0
    | +-- strip-ansi@3.0.1
    | | `-- ansi-regex@2.0.0
    | `-- wrap-ansi@2.0.0
    +-- decamelize@1.2.0
    +-- os-locale@1.4.0
    | `-- lcid@1.0.0
    |   `-- invert-kv@1.0.0
    +-- window-size@0.1.4
    `-- y18n@3.2.1

Want to learn node now 😄

[lebolo]

Any update on this?

In your package.json, this module depends on "request": "2.65.0". You should either change that to "request": "2.74.0" (which is where they bump their tough-cookie dependency) or just loosen your version restriction to "request": "^2.65.0" which would allow updates that are not breaking. I would recommend the latter for all (dev)dependencies, honestly.