Proposed security disclosure policy

[nrc]

Since 1.x releases are a drop-in upgrade, we expect the vast majority of users to be on the latest.

I imagine that some security bugs might be minor enough that they only warrant fixing on nightlies or beta, rather than pushing every one to release. Perhaps you are thinking that these would not be classes as ‘official security bugs’? Which makes me thing that maybe we should be explicit about having a way to say that the reported bug is not actually a security issue? The current proposal seems to imply that every reported bug will be treated as real.

This sounds wrong, unless the security team is larger than I am expecting.

I was thinking of developers within the Rust community rather than users of Rust here. I’m assuming that not everyone who contributes to Rust will be on the security team, but that sometimes their (as in any given contributor) input might be wanted.

[erickt]

Do we have an rfc on how many old versions of rust we are maintaining? I couldn’t find one. Closest I got was 507 and this thread but neither mention it.

[jruderman]

Which bugs are severe enough that they should be hidden from the public (and might be eligible for a future bug bounty)?

For rustc and std:

• Would the Leakpocalypse qualify? It violated Rust’s memory safety guarantees but wasn’t likely to affect applications.
• On the other hand, what about libraries whose incorrect output leads to application vulnerabilities?

For servers:

• Which servers, and which kinds of bugs, are in scope?

• When should researchers feel comfortable testing live sites, and when should they set up their own instances? (Example policy)

[bstrie]

I’d say that Leakpocalypse qualifies. A soundness violation means that you’ve erased Rust’s primary selling point, which is the guarantee that non-unsafe code will be memory-safe. It’s easy to imagine people relying on that quality for the security of their application, even if an exploit is as contrived in practice as Leakpocalypse.

[wycats]

The Ember security policy includes no predisclosure because Ember isn’t shipped with any distribution that may want to include package manager updates as soon as the vulnerability is announced.

In contrast, Ruby on Rails announces the vulnerability to distros@openwall 72 hours before the public announcement.

In Rust’s case, I think it makes sense to notify distros@openwall, since Rust is pretty likely to start getting packaged in at least some distributions pretty soon.

[Manishearth]

Since 1.x releases are a drop-in upgrade

Modulo UFCS?

In case of really severe issues where an exploit could be easily crafted, I suggest pushing out to older releases too.

[sigma]

I think we’d probably need some classification system. Say: “Critical, Important, Moderate, Minor”.

If a bug is posted to the sec list and it’s triaged as Minor or “Not a security issue” it could be punted to the public issue tracker.

If it’s Critical the patch might need pushed back onto some number of previous releases so that distros like debian who’ll probably have ancient versions in their repositories can patch.

What to do with the middle categories I’m not so sure.

[bascule]

I find this cliche rather tiring:

We take security very seriously

Here’s a crack at something different:

“Safety is one of the core principles of Rust, and to that end, we would like to ensure that Rust is a secure language.”

Re:

All security bugs in the Rust distribution should be reported by email to security@rust-lang.org

Perhaps encourage (but do not require) people to GPG encrypt messages sent to this list.

[arielb1]

I don’t think it’s right to handle soundness issues via this process, at least at this stage. rustc’s code isn’t particularly robust, so there are probably many of them - at this stage I really really won’t trust rustc to contain malicious safe-Rust code, and some soundness issues require a significant amount of effort to fix and/or break significant amounts of code.

Until we get much better on that front, I would prefer that only issues that can cause vulnerabilities in application code (e.g. some library function not performing bounds checking in some cases) be reported via the security process.

[arielb1]

I mean, I really wouldn’t want the Leakpocalypse to be handled privately.

[steveklabnik]

Which bugs are severe enough that they should be hidden from the public (and might be eligible for a future bug bounty)?

One thing that I meant to mention is that I’d prefer to decide which bugs count for this policy an RFC, to be kicked off last week. We need the mechanics of reporting in place for 1.0, and we can refine the guideline on what to report over a slightly longer timeframe.

[steveklabnik]

Do we have an rfc on how many old versions of rust we are maintaining?

I do not believe so right now, no.

[steveklabnik]

Perhaps encourage (but do not require) people to GPG encrypt messages sent to this list.

It says it in the last paragraph:

If you would like, you can encrypt your report using our public key.

[alfie]

- delivered to small security team + delivered to a small security team

[alfie]

The Rust project has a 5 step disclosure policy. …

I would bullet point these five steps, rather than keep them in a single (wordy) paragraph.

Other than that, looks good. +1

[Manishearth]

The Leakpocalypse could have been handled privately by immediately destabilizing scoped and suggesting people stop using it. (which is more or less what happened anyway, minus the private ness)

Then after some time make it public and come up with a real solutoon.

[steveklabnik]

Thank you everyone! I have a PR here: https://github.com/rust-lang/rust-www/pull/123

I believe that I’ve addressed everything that’s come up. Please let me know how this looks!

[bluss]

We really need to spell out what a security problem is. Is this about rustc the application, or rust the language?

[Manishearth]

The language (soundness bugs in rustc the language can cause security bugs in other applications); though if the application has a security bug we should use this too.

[bluss]

Ok, so then issue 25549 would qualify as a security bug (it enables violation of memory safety)? It was reported yesterday.

Edit: Now fixed