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

proposal: A security response policy for Go #11502

Closed
jbuberel opened this issue Jul 1, 2015 · 38 comments
Closed

proposal: A security response policy for Go #11502

jbuberel opened this issue Jul 1, 2015 · 38 comments

Comments

@jbuberel
Copy link

jbuberel commented Jul 1, 2015

As the use of Go in security-sensitive applications grows, I believe it is time that Go had a more formal policy on how security problems are handled.

We could start with the creation of a 'security@golang.org' email address that would be used to report suspected security issues. Those messages would be reviewed by a small group ("Go security review team") with a commitment to a 24-hour initial triage and review.

Based on the assessed severity of the report, the security review team would assign it to one of these categories:

  • Not a security problem, and the reporter will be asked to submit a regular bug report instead.
  • A security problem that should be fixed, but is not being actively exploited.
  • A security problem that is being actively exploited and must be addressed immediately.

The standard Google policy, which Go would be minimally obligated to adhere to is:

  • 90-days to fix regular security issues before the details can be made public
  • 7-days to fix actively exploits before details can be made public
@adg
Copy link
Contributor

adg commented Jul 1, 2015

FYI, the security@golang.org email address already exists.

It's mentioned here and in the main repo's CONTRIBUTING.md file.

@josharian
Copy link
Contributor

A security problem that is being actively exploited and must be addressed immediately.

Would an actively exploited security problem in the standard library or gc toolchain thus automatically trigger a point release? Releases, even minor ones, are a fair amount of work. At the very least, I think we'd want to say something about severity here, which is orthogonal to active exploitation.

@rsc
Copy link
Contributor

rsc commented Jul 1, 2015

I think if it's not worth issuing a point release for, then it's "not a security problem" aka bullet 1.

@jbuberel
Copy link
Author

jbuberel commented Jul 3, 2015

Also note that I've omitted any mention of "early partner disclosure". This means the policy would not allow for notification of packagers or binary distributions. Based on my discussions with the security teams that put together the Chrome, Android, Dart and Angular security policies, these advanced disclosures have a very high chance of becoming public and causing more damage.

Their recommendation was simple to issue a statement, upon receipt of the security issue, that "We are planning to release version x.y.z on date YYYY-MM-DD. We recommend that all users upgrade to this release when it becomes available."

@jbuberel
Copy link
Author

jbuberel commented Jul 3, 2015

@josharian I agree that severity and urgency should be treated separately.

Perhaps something along the lines of:

Security issues will be ranked according to their severity [S1-S3]
S1 - Would allow remote execution of code or privilege escalation via running Go programs
S2
S3 - Requires modification to source to be exploited

Urgency [U1-U3]
U1 - Is being actively exploited
U2
U3 - No known exploits in the wild

Along with a guideline that a point release would normally be made for issues with either S1 or U1, or S2 and U2.

@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Jul 11, 2015
@reedloden
Copy link

See also http://www.rust-lang.org/security.html, as well as the back discussion in https://internals.rust-lang.org/t/proposed-security-disclosure-policy/2024

sparklemotion/nokogiri#1191 also has some other useful info.

@jbuberel
Copy link
Author

Thanks for the links - give me a bit to review.

@jbuberel
Copy link
Author

@reedloden - I definitely like the Rust policy - http://www.rust-lang.org/security.html

The python equivalent - https://www.python.org/news/security/ - is a little too glib for my liking. The WebKit policy - https://www.webkit.org/security/ - includes a process for becoming a member of the security review team, which is interesting, but probably too much for our needs (IMO).

The Xen Project - http://www.xenproject.org/security-policy.html - also contains an official embargo process, which I would prefer to avoid.

Are there others that we should be evaluating? I'm inclined to start with the Rust policy as a template, and customize slightly for Go.

@jbuberel
Copy link
Author

@adg - could I get your arbiter stamp of approval to proceed with a first draft of a policy, based on Rust, that would eventually be hosted at:

http://golang.org/security

@reedloden
Copy link

@jbuberel, there's also http://rubyonrails.org/security/ (text seems mostly the same as some of the others [includes EOL info], though they use https://hackerone.com for submissions rather than a security@ address).

Glad to see you guys getting a policy in place. :)

@jbuberel
Copy link
Author

@reedloden I did take a look through the hackerone.com product. I've never used it before and it does look interesting. But given that the Go project doesn't exactly have budget for bug bounties, it seems like a bit more than we need. Thoughts?

@adg
Copy link
Contributor

adg commented Jul 30, 2015

@jbuberel LGTM for a policy based on the Rust one.

On 30 July 2015 at 11:59, Jason Buberel notifications@github.com wrote:

@reedloden https://github.com/reedloden I did take a look through the
hackerone.com product. I've never used it before and it does look
interesting. But given that the Go project doesn't exactly have budget for
bug bounties, it seems like a bit more than we need. Thoughts?


Reply to this email directly or view it on GitHub
#11502 (comment).

@reedloden
Copy link

@jbuberel -- HackerOne isn't just for bug bounties (seems to be a common misconception), and plenty of open source projects use the platform (for free) without paying any bounties at all. It's just a great way to manage incoming reports, interact with the researcher(s), and handle public disclosure in the end. I've always felt that security@ mailboxes are terrible, as it just makes it so difficult to keep up with things, see the current status of issues, and make sure everybody is on the same page. IMHO, the platform speaks for itself, so just take a look at some of the publicly disclosed reports on https://hackerone.com/rails to see how it works in action.

Disclaimer: I lead security for HackerOne. Doing my best not to be sales-y at all here (I truly feel the platform works great for dealing with incoming security reports). However, the main thing is just to have a defined process that works for everybody and is followed. Whether that's just some private e-mail address or use of some platform or whatever in the end.

Happy to help in any way I can... As I said, security is my full-time job, so used to dealing with this stuff and helping out other companies and OSS projects figure out something that works for them.

@bradfitz
Copy link
Contributor

We've been burned enough by services both going away and changing on us. Email may not be ideal in all respects, but it works, has been around for awhile, should survive a bit longer, and people on both sides know how to use it.

@fweimer
Copy link
Contributor

fweimer commented Jul 31, 2015

@reedloden, HackerOne's terms are completely at odds with the coordinated disclosure process which has evolved over the years. HackerOne assumes control over the process, which is completely impossible if we are dealing with a cross-vendor issue.

@reedloden
Copy link

@fweimer, not sure where you're getting that, but none of that is true at all. Perhaps thinking of one of our competitors? Happy to discuss further off this thread. Feel free to drop me a note at reed [@] hackerone.com.

Anyway, my comments have derailed this issue way too much, and I do apologize. I only explained stuff about HackerOne because @jbuberel asked for my thoughts.

Would like to bring the conversation back to focusing on getting Go a vulnerability response policy that works for everybody and ensures all the right things are done. Sounds like people feel Rust's policy is a good start, so seems like getting a draft together based on that would be a reasonable next step. Happy to help with that if needed.

@fweimer
Copy link
Contributor

fweimer commented Jul 31, 2015

@jbuberel, I expect most GNU/Linux distributions would be fine if Rust adopted the Go process, maybe with the caveat that it might be a bit inconvenient if the 72 hour pre-disclosure period includes a weekend.

@jbuberel
Copy link
Author

CL submitted for the proposal, with a full draft of the actual policy here:

https://go-review.googlesource.com/#/c/13007

@fweimer
Copy link
Contributor

fweimer commented Jul 31, 2015

@jbuberel, the CL seems garbled/word-wrapped, destroying the markup.

I think the claim that embargoes are not working due to leaks does not work out in practice. Short embargoes are generally unproblematic. Notifying the private distros list on the same day as the commit does not make sense, you can just wait for the commit and notify the public oss-security list.

You really should add security-related regression tests to the public test suite, which means you have to reveal details about exploitation. This also helps those (like Debian) who have to keep alive older branches much longer than you do.

The bigger challenge is to consistently identify fixes as security-relevant if they stem from a non-security bug report. (This is what large projects like Linux, LibreOffice, and smaller ones such as GNU libc are struggling with.) Maybe the policy could say something about that.

@gopherbot
Copy link

CL https://golang.org/cl/13007 mentions this issue.

@jbuberel
Copy link
Author

jbuberel commented Aug 3, 2015

@fweimer I blame SublimeText for not properly wrapping. A new patchset will be uploaded shortly to address that. Sorry!

Regarding the early disclosure and embargo, if I understand you correctly, you are suggesting the following process:

  1. Notification is received, threat analyzed.
  2. Fixes are created, but patches are not committed to the public repo.
  3. Send email to distros@openwall with details and patch contents.
  4. Wait 72 hours (or 3 business days, etc.)
  5. Commit patches to public repo, upload new binary builds
  6. Send public announcement.

Regarding the problem of identifying security-relevant issues, I added a section (below). Let me know if you think that is sufficient.

Flagging Existing Issues as Security-relevant

If any member of the community believes that an existing issue is security-relevant, we ask that they send an email to security@golang.org. The email should include the issue ID and a short description of why it should be handled according to this security policy.

@fweimer
Copy link
Contributor

fweimer commented Aug 3, 2015

@jbuberel, the list of six steps matches more closely what many mature upstream projects currently do.

On the other hand, many Go users will have to recompile their application anyway and cannot simply run yum upgrade or apt-get update && apt-get dist-upgrade to apply the fixes to their systems, which means that maybe the pre-notification is less relevant in the Go context.

Personally, I would suggest to try the three-day-embargo for a while, see how it works, and make adjustments as necessary.

@jbuberel
Copy link
Author

jbuberel commented Aug 3, 2015

@fweimer, sounds reasonable to me. Third patch set uploaded to include a "3 business day" embargo before the public announcements are made.

gopherbot pushed a commit to golang/proposal that referenced this issue Aug 4, 2015
A proposal to adopt a formal security policy for the Go
project. Based primarily on the rust-lang@ policy.

Udates: golang/go#11502

Change-Id: Ie29088740c28fce1d7a953830405a22c235fa02f
Reviewed-on: https://go-review.googlesource.com/13007
Reviewed-by: Andrew Gerrand <adg@golang.org>
@adg
Copy link
Contributor

adg commented Aug 4, 2015

Jason's proposal is available for review here: https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

@reedloden
Copy link

Anyway to set up a security announcement list? Having to subscribe to
golang-dev seems awkward.

On Tuesday, August 4, 2015, Andrew Gerrand notifications@github.com wrote:

Jason's proposal is available for review here:
https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md


Reply to this email directly or view it on GitHub
#11502 (comment).

@davecheney
Copy link
Contributor

We already have golang-announce. Would that suffice ?

On Wed, Aug 5, 2015 at 11:31 AM, Reed Loden notifications@github.com
wrote:

Anyway to set up a security announcement list? Having to subscribe to
golang-dev seems awkward.

On Tuesday, August 4, 2015, Andrew Gerrand notifications@github.com
wrote:

Jason's proposal is available for review here:

https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md


Reply to this email directly or view it on GitHub
#11502 (comment).


Reply to this email directly or view it on GitHub
#11502 (comment).

@reedloden
Copy link

Nope. That's fine. golang-dev is specifically called out in the proposal.
Seems like that should focus on golang-announce (and also send a notice to
golang-dev and golang-nuts).

On Tuesday, August 4, 2015, Dave Cheney notifications@github.com wrote:

We already have golang-announce. Would that suffice ?

On Wed, Aug 5, 2015 at 11:31 AM, Reed Loden <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Anyway to set up a security announcement list? Having to subscribe to
golang-dev seems awkward.

On Tuesday, August 4, 2015, Andrew Gerrand <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Jason's proposal is available for review here:

https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md


Reply to this email directly or view it on GitHub
#11502 (comment).


Reply to this email directly or view it on GitHub
#11502 (comment).


Reply to this email directly or view it on GitHub
#11502 (comment).

@jbuberel
Copy link
Author

jbuberel commented Aug 5, 2015

@reedloden Agreed - golang-announce@ should be used instead. I'll update the proposal to reflect that.

@fweimer
Copy link
Contributor

fweimer commented Aug 5, 2015

@jbuberel It may also make sense to request the CVE ID via the distros list (or privately from Debian or Red Hat, if you'd prefer that), otherwise you will have to wait for assignment from other sources.

@jbuberel
Copy link
Author

jbuberel commented Aug 5, 2015

@fweimer Good suggestion. I'll update the proposal to specify that list for CVE-ID requests.

@mpl
Copy link
Contributor

mpl commented Aug 5, 2015

@jbuberel in case you missed it, I pointed out a small typo in the CL (after it was merged)

@jbuberel
Copy link
Author

jbuberel commented Aug 6, 2015

@mpl Yep, I saw that and have updated my local copy to include the fix. I send a new patch under a new CL shortly with a few additional fixes/changes.

@jbuberel
Copy link
Author

jbuberel commented Aug 6, 2015

@gopherbot
Copy link

CL https://golang.org/cl/13283 mentions this issue.

gopherbot pushed a commit to golang/proposal that referenced this issue Aug 11, 2015
Udates: golang/go#11502

- Fix spelling of Adam Langley's last name.
- Specify that the distros-openwall list will be
used to request CVE IDs
- List the full set of mailing list addresses that
will receive security announcements
- Specify that the primary email list for security
announcements will be golang-announce@
- Remove the @golang.org from the golang-announce list name.
- Added agl@google.com and adg@golang.org as human
contacts.
- Added the public key for security@golang.org
- Removed reference to Andrew's missing PGP key

Change-Id: Ia6215b5e9d1d3ee96a015e17313aba52c4d9e0d9
Reviewed-on: https://go-review.googlesource.com/13283
Reviewed-by: Andrew Gerrand <adg@golang.org>
@jbuberel
Copy link
Author

We're getting close to the final version - please take one last look:

https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

If there is no additional changes to be made, the "Implementation" section will be HTML-ified and posted at golang.org/security.

@fweimer
Copy link
Contributor

fweimer commented Aug 11, 2015

@jbuberel Minor typo: “and the oss-security@openwall” should be “and oss-security@openwall”. Otherwise, looks reasonable.

@jbuberel
Copy link
Author

@fweimer - fixed

@gopherbot
Copy link

CL https://golang.org/cl/13955 mentions this issue.

adg added a commit that referenced this issue Sep 3, 2015
Bring in the text from the proposal (with minor edits):
https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

Fixes #11502

Change-Id: I92a987be66a0df60c1fad6c6c79f89bd8e9c12a8
Reviewed-on: https://go-review.googlesource.com/13955
Reviewed-by: Jason Buberel <jbuberel@google.com>
adg added a commit that referenced this issue Sep 3, 2015
Bring in the text from the proposal (with minor edits):
https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md

Fixes #11502

Change-Id: I92a987be66a0df60c1fad6c6c79f89bd8e9c12a8
Reviewed-on: https://go-review.googlesource.com/13955
Reviewed-by: Jason Buberel <jbuberel@google.com>
Reviewed-on: https://go-review.googlesource.com/14224
Reviewed-by: Andrew Gerrand <adg@golang.org>
@golang golang locked and limited conversation to collaborators Sep 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests