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

Should security-events: read be considered a dangerous permission? #3131

Open
diogoteles08 opened this issue Jun 6, 2023 · 13 comments
Open
Labels
kind/enhancement New feature or request Stale

Comments

@diogoteles08
Copy link
Contributor

Is your feature request related to a problem? Please describe.

The security-events: read grants permissions to read security issues that are privately reported to the repository. This can became dangerous as attackers might have access to vulnerabilities that were not yet resolved and/or not publicly disclosed.

Impacts of this decision

  1. This is closely related to the issue Feature: Allow unpinned in non-privileged workflows #2018 , that states that unpinned actions should be punished only if called with dangerous permissions.
  2. This decision should also make us re-evaluate if the Token-Permission check should somehow punish a top-level permissions: read-all, as it includes the security-events: read.
@spencerschrock
Copy link
Member

I'm leaning towards "dangerous".

2. This decision should also make us re-evaluate if the Token-Permission check should somehow punish a top-level permissions: read-all, as it includes the security-events: read.

In my opinion yes. If you look at the restricted permissions in GitHub docs, they take a much more restricted approach for defaults. I think the read-all approach is a good start but broad:
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

@evverx
Copy link
Contributor

evverx commented Jun 7, 2023

According to https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Maximum access for pull requests from public forked repositories is read

which means that it's possible to just open a PR, set security-events to read and it should be granted. I wonder if it's actually possible to access security advisories like that? I thought repository_advisories was responsible for that: https://docs.github.com/en/rest/security-advisories/repository-advisories?apiVersion=2022-11-28

@evverx
Copy link
Contributor

evverx commented Jun 9, 2023

If by "security issues that are privately reported to the repository" you meant the security dashboard looks like its possible for random PRs to dump it using https://docs.github.com/en/rest/code-scanning?apiVersion=2022-11-28#list-code-scanning-alerts-for-a-repository: evverx/elfutils#120. If that dashboard is considered private it should be reported to the GitHub security probably first because there is nothing projects can do to fix that.

Let me see if I can dump the advisories :-)

@evverx
Copy link
Contributor

evverx commented Jun 9, 2023

Luckily it seems only the security dashboard can be dumped: https://github.com/evverx/elfutils/actions/runs/5219302340/jobs/9420978964. (The second curl command was responsible for dumping the advisories there).

@evverx
Copy link
Contributor

evverx commented Jun 9, 2023

Just to sump up as long as random PRs can freely elevate their read privileges like that it doesn't matter what projects do. I guess it would be better if projects use, say, contents: read but that would be cosmetic because it's always possible for PRs to get permissions: read-all. The maximum access for pull requests from public forked repos is what actually matters. It should be set to none by GitHub to actually fix that.

@diogoteles08
Copy link
Contributor Author

Thanks a lot for the investigation work @evverx! That's really revealing that a forked PR can create and run a workflow with permissions: read-all no matter what are the permissions defined on the workflows of the original repo.

But giving your discovery that it's possible to dump the security-dashboard with security-events: read but it's not possible to dump the advisories, I come back to the question: is security-events: read really unsafe? Because:

  1. Seems that this permission is used only to read results of code-scanning(check the usage of this permission here), which I suppose have only the code as input, which is public.
  2. As @evverx well pointed, this documentation says that you can only read "unpublished security advisories from a repository if you are a security manager or administrator of that repository". So I guess that even if you have the read-all permission, you still will be limited by your GitHub account.

@evverx
Copy link
Contributor

evverx commented Jun 9, 2023

According to https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/managing-code-scanning-alerts-for-your-repository

You need write permission to view a summary of all the alerts for a repository on the Security tab.

so I'd say this particular privilege boundary can be crossed :-)

If projects don't use anything apart from CodeQL they should be fine because it's possible to see the same CodeQL alerts by forking repos and triggering CodeQL there :-) Third-party analyzers with their own tokens writing stuff to the security dashboard are much more interesting.

@evverx
Copy link
Contributor

evverx commented Jun 11, 2023

For the record I reported that issue to GitHub. I don't participate in bug bounty programs so I reported it via their usual bug tracker. I think either all the alerts including comments explaining why stuff is dismissed should be private as advertised or the alerts should be public so as not to mislead people into thinking that they can keep sensitive stuff there. I'll post their reply here once it's resolved one way or another.

@diogoteles08
Copy link
Contributor Author

Thanks @evverx! Do you have any link to the bug you created? I could "thumbs up" if possible

@evverx
Copy link
Contributor

evverx commented Jun 12, 2023

It's ticket #2199640 but I'm not sure it can be viewed by anyone other than me and GH. I linked that ticket to this issue though so it should be visible there at least.

@diogoteles08
Copy link
Contributor Author

Hm sad, but I guess that's what can be done by now. Thanks again, great job!

@github-actions
Copy link

github-actions bot commented Sep 7, 2023

Stale issue message

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 16, 2023
Copy link

This issue is stale because it has been open for 60 days with no activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request Stale
Projects
Status: No status
Development

No branches or pull requests

4 participants
@spencerschrock @evverx @diogoteles08 and others