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

SECURITY-PROCESS.md: document severity levels #10118

Closed
wants to merge 4 commits into from

Conversation

bagder
Copy link
Member

@bagder bagder commented Dec 19, 2022

No description provided.

@tlhackque
Copy link

This should reference the earlier discussion of what merits an out of band release. The two should be consistent...

Other considerations would include:

  • Does it disclose credentials
  • Is data corrupted (local, remote)
  • Does it require that the remote server is compromised
  • Does it require that the local host is compromised
  • What are the effects on server and host? Resource issues that effect other processes? Or just the ones talking?

Some of these are specific examples of the general statements in the proposal. But it's worth having examples to help with interpreting the generalizations.

@bagder
Copy link
Member Author

bagder commented Dec 19, 2022

This should reference the earlier discussion of what merits an out of band release. The two should be consistent...

The Early release text documents when to do early releases and one of the criteria is if there's a High or Critical security issue. I think that alignment suffice.

  • Does it disclose credentials

I think it already says. But the question is not only if it can do it, it is also how likely, how often and how hard it is to make it do that.

  • Is data corrupted (local, remote)

A curl security issue can hardly be responsible for remote data corruption, can it? How would that work?

  • Does it require that the remote server is compromised

No security issue can require that because a server might just as well be plain malicious without being compromised, and then it can do the same damage or tricks.

  • Does it require that the local host is compromised

I can't think of a way to get this into text that actually adds value. curl can only work if it has a platform to stand on that plays by established rules. If something changes those fundamentals, then of course all bets are off. But I'm not sure that is what you are talking about?

  • What are the effects on server and host?

I don't understand this. Surely effects on servers are not curl issues?

Resource issues that effect other processes? Or just the ones talking?

I'm not sure how this will help our text.

Some of these are specific examples of the general statements in the proposal. But it's worth having examples to help with interpreting the generalizations.

I would be happy to, but I have not been able to come up with specific examples that firmly and always fall into a specific level. There are simply too many factors and moving pieces that can change how we view issues.

@icing
Copy link
Contributor

icing commented Dec 20, 2022

Are there any effectual differences between high and critical? Will we or are we expecting our users to act differently on those?

@bagder
Copy link
Member Author

bagder commented Dec 20, 2022

Are there any effectual differences between high and critical? Will we or are we expecting our users to act differently on those?

Good question.

I think in general the practical difference between these two is minimal. Except perhaps in panic level among readers of advisories. I think maybe there is still value in keeping both, if nothing else because those four levels are the exact levels used by our bug-bounty program and the IBB program that pays our bug-bounty rewards. If we would remove critical, we also take away the top-tier reward level. Or we would need to introduce another method to map our severity levels to hackerone levels.

Maybe we can express a better separation between the two highest severity levels?

This said, we have never marked a single curl security vulnerability critical.

@icing
Copy link
Contributor

icing commented Dec 20, 2022

Makes sense to keep it then, if bug bounties are classified along this.

@emilengler
Copy link
Contributor

I think it would be great, if each security level would contain one or two examples of previous vulnerabilities, that would have fallen into one of these levels.

@bagder bagder closed this in 07dfbc0 Dec 21, 2022
@bagder bagder deleted the bagder/security-severity branch Dec 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants