Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6 vulnerabilities #153

Open
hubdotcom opened this issue Aug 7, 2017 · 4 comments
Open

6 vulnerabilities #153

hubdotcom opened this issue Aug 7, 2017 · 4 comments

Comments

@hubdotcom
Copy link

Known Vulnerabilities

Vulnerabilities with a fix
An upgrade or patch is available to fix the vulnerable dependencies.

Prototype Override Protection Bypass in qs
Timing Attack in http-signature
Regular Expression Denial of Service (DoS) in ms
Regular Expression Denial of Service (ReDoS) in ms
Remote Memory Exposure in request
Uninitialized Memory Exposure in tunnel-agent

@danieltian
Copy link

These vulnerabilities are in the dependencies, not in Nuts itself. Updating to the most recent versions of the dependencies should fix most, if not all of these. However, even without updating, I doubt any of these are real concerns, considering that the vulnerable libraries are dependencies of dependencies.

@skewart
Copy link

skewart commented Oct 10, 2017

However, even without updating, I doubt any of these are real concerns, considering that the vulnerable libraries are dependencies of dependencies.

How is a vulnerability in a dependency of a dependency not a real concern? You're still running the code in your app, regardless of how exactly it got there.

Granted, it might not be easy for people to do anything about it by changing code in the Nuts repo - you'd have to remove the dependency that depends on a something with a vulnerability. It still seems like a concern though.

@danieltian
Copy link

danieltian commented Oct 10, 2017

Take a closer look at the vulnerabilities:

Prototype Override Protection Bypass - in body-parser and request. If given malicious input, it can override object prototypes. But in Nuts, you'd only initiate a HTTP request to URLs that you control or to trusted URLs (like GitHub).

Regular Expression Denial of Service (DoS) - in body-parser -> debug -> ms, can create an interval string that takes a long time for regex to parse. This is used internally by debug to create human-readable time diffs. There's no way to feed ms a string from body-parser through debug. Even assuming the user could somehow trigger this vulnerability, all that would accomplish is the user DoS'ing themselves.

Remote memory exposure - in request, can expose memory with a malformed request body. Even the description for this vulnerability says that it's likely difficult to perform because it requires that the body type be controllable by the end user, which Nuts does not do.

Timing attack - in request -> http-signature, can guess the signature one character at a time based on the time it takes to process the request. Except all the user would be able to do is guess their own signature.

Uninitialized memory exposure - in tunnel-agent. Uninitialized buffers are created. The buffer would need to be exposed to the user somehow so that they can see the memory contents of their own computer.

Denial of Service - in superagent, it's possible to create a zip file that causes high CPU usage when unzipping. Someone using Nuts to push out an update for their app can serve up a malicious zip file, but no app author is going to do this.

So yes, there are vulnerabilities, but either they are not exploitable, or are very difficult to exploit. And the end result is that the user either DoS'es themselves, or exposes their own memory to themselves.

Either way, this project is dead, and if someone really cares that much about fixing the vulnerabilities, they can simply fork the repo and update the dependencies.

@skewart
Copy link

skewart commented Oct 11, 2017

That makes sense. It's not a big deal because the vulnerabilities themselves are not very severe in practice. It sounded like you were saying they're not a problem because they're in dependencies of dependencies. I see you were actually saying they're simply not really problematic vulnerabilities.

Thanks for the more detailed explanation and summaries of the vulnerabilities!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants