Dear GNU Radio community,
today, we received a security advisory via the contact method we offer in a canonical
place [1], alerting us to the following:
The github CI workflow that can be used to re-render the conda template gets triggered and
executed without checking that the author of the triggering PR has CI privileges. (For the
CI that gets run when you open a PR, you need to be trusted, or else a maintainer needs to
click on "Approve CI run" every time you post or update a CI; this is not true for the
github "issue_comment" trigger, which honestly is, in line with the rest of github CI's
documentation style, something you can infer with enough experience, from sources outside
Github documentation. We didn't infer that, and we wonder why there are action security
controls that do not apply to all ways to trigger actions. Still, it's our responsibility
to keep things safe, and assuming controls work without checking seems to be something we
need to add to our list of things to do when working with public CI.)
That would have allowed an attacker to open a PR that does something nefarious (attack
webservers, mine cryptocurrency, exfiltrate CI secrets, modify commits/source code).
We received this report from Wang-Meimei, for which we are very thankful.
Steps taken:
1. simply removed that workflow. That makes it impossible to trigger from PRs, even should
they add it back: it needs to exist on the main branch to work. I have not been able to
get the workflow to function correctly in the last six months, so functionally, this is
not a restriction of our abilities.
2. investigated workflow runs of the past year. No execution of that workflow, aside from
my own, have been found. There have not been any inconsistencies of the main branch
history with local copies, so we can preclude any code modifications.
3. Started a review of the repository action secrets stored in github. As mentioned in 2.,
we are certain enough this was not exploited, but we are still working to rotate secrets,
and flush caches where applicable. ("abundance of caution", but really, we should just be
doing that in a situation like this, without needing to think about it.)
Special thanks, again, go out to Wang-Meimei, who's been very helpful in their
reporting.
Best regards,
Marcus Müller
[1] as described in RFC 9116: https://gnuradio.org/.well-known/security.txt
