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

[diogoteles08]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[evverx]

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]

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

[github-actions]

Stale issue message

[github-actions]

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