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

doc: describe what security issues are #14485

Merged
merged 1 commit into from
Sep 7, 2017

Conversation

sam-github
Copy link
Contributor

Fix nodejs/security-wg#18

Checklist
Affected core subsystem(s)

doc,security

@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Jul 25, 2017
README.md Outdated
the Node.js application or its system for which the attacker does not already
have the capability.

To illustrate the point, here are some examples of issues that are not
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: "examples" (plural) but there appears to be only one example provided

@Trott
Copy link
Member

Trott commented Jul 25, 2017

Can we link to a separate doc rather than putting the text right in the README? (Maybe the doc can even live in the security-wg repl?)

@sam-github
Copy link
Contributor Author

This is an attempt to clarify what kinds of issues will or will not be considered "security vulnerabilities" by the Security Response Team. I lifted much of the text from https://www.python.org/news/security/, because Node.js is not a Web Browser, it does not allow (natively) remote code execution, so has a different security model from Browsers, which has occaisonally created confusion.

README.md Outdated
@@ -173,6 +173,23 @@ Your email will be acknowledged within 24 hours, and you’ll receive a more
detailed response to your email within 48 hours indicating the next steps in
handling your report.

There is not any hard and fast rule to determine if a bug is worth reporting.
Copy link
Member

@Trott Trott Jul 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Consider changing worth reporting here and below to something else? If it's a bug, it's worth reporting. It's just a question of whether it's a security issue or whether the bug is in Node.js itself or end-user code.

Maybe change this entire sentence to:

It can be difficult to determine if an issue is a valid security issue or not.

Then change any attack worth reporting via the security address in the next sentence to a valid security issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clarified

@sam-github
Copy link
Contributor Author

@Trott we can spread our docs as thin as we like, through multiple github repos (nodejs/node, nodejs/LTS, nodejs/security-wg), and through various files, and wikis, but I don't find that helpful.

This is the point at which people are told where to report security issues, its the point they should be told what to report as well, IMO.

There is no current place in the security-wg repo that this information fits. It doesn't have any relationship to any other info in the README (https://github.com/nodejs/security-wg/blob/master/README.md), and I could just dump the text in a standalone .md file and link to it, but that seems a bit odd to me.

README.md Outdated
There is not any hard and fast rule to determine if a bug is worth reporting as
a security issue. The general rule is any issue worth reporting via the
security address must allow an attacker to affect the confidentiality, integrity
and availability of the Node.js application or its system for which the attacker
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: and -> or?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think its accurate as is. Its a security issue if it affect the app OR the system the app is on (either one). Its not necessary that it effect the app AND the system.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sam-github I think you misread me. I'm talking about changing and to or, not the other way around. Right now, it says it's a valid security issue if it affects "the confidentiality, integrity, and availability of the Node.js application...". I think it should say `or availability of the Node.js application...". Like, if you can affect availability, that's a security issue even if it doesn't also affect confidentiality.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did misreadh, changed.

README.md Outdated
@@ -173,6 +173,23 @@ Your email will be acknowledged within 24 hours, and you’ll receive a more
detailed response to your email within 48 hours indicating the next steps in
handling your report.

There is not any hard and fast rule to determine if a bug is worth reporting as
a security issue. The general rule is any issue worth reporting via the
security address must allow an attacker to affect the confidentiality, integrity
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it may be worth defining "attacker" here. What abilities does the attacker have? (e.g., do they interface with the system over HTTP, fs, etc.?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you suggest some wording? Couldn't an attacker could have any capability, where the important thing is they are attempting to do something they are not intended to be able to do? That is, that they are attempting to escalate privilege? Of course, as the capability of executing arbitrary js code is already the highest privelege, escalation from there is not possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, that makes sense. I think what threw me off is the whole no-escalating-above-arbitrary-js-code is explained in the example. I think it might help clarify to pull it up to this paragraph.

Given that the definition is fairly abstract, it would also be helpful to have a few examples of attackers, along with escalations that would be considered security vulnerabilities. I imagine that we're often thinking of attackers as HTTP clients that try to escalate above being able to send HTTP messages to the system. It's clear that being able to remotely execute code from an HTTP request is an escalation that would be considered a security vulnerability, but are there examples of more subtle escalations that would count?

Showing examples of particular issues that were in fact considered security issues would also help. Do we have examples we can use? I think nodejs/security-wg#17 will help us get good examples: having a private disclosure process that retroactively turns public once the issue is resolved will make the boundaries more clear.

@sam-github
Copy link
Contributor Author

I'm going to go through the sec release history and try to find some good examples, as in https://www.python.org/news/security/, that flesh out the kinds of things Node does and does not consider a vulnerability.

README.md Outdated
- Causing program termination using either the public Javascript APIs or the
private bindings layer APIs. Doing so requires the ability to execute
arbitrary Javascript code, which is already the highest level of privilege
possible.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd agree more examples, including some positive examples would be useful.

@sam-github
Copy link
Contributor Author

sam-github commented Aug 1, 2017

possible examples:

8.0.0

  • new Buffer(num) and Buffer(num) will zero-fill new Buffer instances
    [7eb1b4658e]
    #12141.

  • buffer: Zero-fill excess bytes in new Buffer objects created with
    Buffer.concat() while providing a totalLength parameter that exceeds the
    total length of the original Buffer objects being concatenated. (Сковорода
    Никита Андреевич)
    ref: https://github.com/nodejs/node-private/pull/64
    ref: 8fb8c46303

  • url.resolve may transfer the auth portion of the url when resolving between two full hosts, see #1435.

4.8.3

  • tls:
    • fix rare segmentation faults when using TLS

nodejs/security-wg#35 (comment)

@sam-github sam-github force-pushed the define-vulnerability branch 2 times, most recently from e646d3d to e46d161 Compare August 22, 2017 17:11
README.md Outdated
@@ -173,6 +173,51 @@ Your email will be acknowledged within 24 hours, and you’ll receive a more
detailed response to your email within 48 hours indicating the next steps in
handling your report.

There is not any hard and fast rule to determine if a bug is worth reporting as
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/There is not any hard and fast rule/There are no hard and fast rules

README.md Outdated
@@ -173,6 +173,51 @@ Your email will be acknowledged within 24 hours, and you’ll receive a more
detailed response to your email within 48 hours indicating the next steps in
handling your report.

There is not any hard and fast rule to determine if a bug is worth reporting as
a security issue. The general rule is any issue worth reporting via the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd strike via the security address

README.md Outdated
@@ -173,6 +173,51 @@ Your email will be acknowledged within 24 hours, and you’ll receive a more
detailed response to your email within 48 hours indicating the next steps in
handling your report.

There is not any hard and fast rule to determine if a bug is worth reporting as
a security issue. The general rule is any issue worth reporting via the
security address must allow an attacker to affect the confidentiality, integrity
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/affect/compromise

README.md Outdated
a security issue. The general rule is any issue worth reporting via the
security address must allow an attacker to affect the confidentiality, integrity
or availability of the Node.js application or its system for which the attacker
does not already have the capability.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "for which the attacker does not already have the capability" is a bit odd. Perhaps just strike that part?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have the right to run arbitrary js code, calling process.exit() isn't a vuln. If you have the mysql credentials, being able to dump the DB isn't a vuln. If you need shell access to execute an exploit that gives you shell access, its not a vuln. I think this is important, a vulnerability allows capability escalation, if you already have the capability, it isn't a vuln.

@jasnell
Copy link
Member

jasnell commented Aug 24, 2017

I think I'd much prefer to see this in a doc/guides document rather than the readme

@sam-github
Copy link
Contributor Author

I think I'd much prefer to see this in a doc/guides document rather than the readme

As I said:

This is the point at which people are told where to report security issues, its the point they should be told what to report as well, IMO.

But its more important that it is doced and easily findable from the place the security reporting email address is descibed, so I'll move it.

Can you give me an explicit location and title?

@sam-github
Copy link
Contributor Author

@jasnell, gentle ping, I know you are juggling eggs ATM

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@sam-github sam-github force-pushed the define-vulnerability branch 2 times, most recently from aa357de to cca378b Compare September 7, 2017 20:43
PR-URL: nodejs#14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
@sam-github sam-github merged commit 7540821 into nodejs:master Sep 7, 2017
@sam-github sam-github deleted the define-vulnerability branch September 7, 2017 20:50
MylesBorins pushed a commit that referenced this pull request Sep 10, 2017
PR-URL: #14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
@MylesBorins MylesBorins mentioned this pull request Sep 10, 2017
MylesBorins pushed a commit that referenced this pull request Sep 11, 2017
PR-URL: #14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
MylesBorins pushed a commit that referenced this pull request Sep 12, 2017
PR-URL: #14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
addaleax pushed a commit to addaleax/node that referenced this pull request Sep 13, 2017
PR-URL: nodejs#14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
MylesBorins pushed a commit that referenced this pull request Sep 20, 2017
PR-URL: #14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
@MylesBorins MylesBorins mentioned this pull request Sep 20, 2017
MylesBorins pushed a commit that referenced this pull request Sep 21, 2017
PR-URL: #14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
MylesBorins pushed a commit that referenced this pull request Sep 26, 2017
PR-URL: #14485
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
@tniessen tniessen mentioned this pull request Apr 13, 2018
2 tasks
tniessen added a commit that referenced this pull request Apr 13, 2018
PR-URL: #20011
Refs: #14485
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
jasnell pushed a commit that referenced this pull request Apr 16, 2018
PR-URL: #20011
Refs: #14485
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
BridgeAR pushed a commit to BridgeAR/node that referenced this pull request May 1, 2018
PR-URL: nodejs#20011
Refs: nodejs#14485
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants