←back to thread

Public secrets exposure leads to supply chain attack on GitHub CodeQL

(www.praetorian.com)
297 points cyberbender | 1 comments | 30 Mar 25 19:54 UTC | HN request time: 0.252s | source
Show context
nyrikki ◴[30 Mar 25 21:51 UTC] No.43528008[source]▶
No mention why this temp token had rights to do things like create a new deployments and generate artifact attestations?

For their fix, they disabled debug logs...but didn't answer if they changed the temp tokens permissions to something more appropriate for a code analysis engine.

replies(6): >>43528290 #>>43531049 #>>43533461 #>>43538343 #>>43538350 #>>43545199 #
declan_roberts ◴[30 Mar 25 22:21 UTC] No.43528290[source]▶
I think we all know this old story. The engineer building it was getting permission denied so they gave it all the permissions and never came back and right-sized.
replies(2): >>43528378 #>>43528414 #
setr ◴[30 Mar 25 22:36 UTC] No.43528414[source]▶
Does any RBAC system actually tell you the missing permissions required to access the object in question? It’s like they’re designed to create this behavior
replies(4): >>43528495 #>>43528507 #>>43529353 #>>43534107 #
Normal_gaussian ◴[30 Mar 25 22:47 UTC] No.43528507[source]▶
Yes. Most auth systems do to the developer - GCP & AWS IAM give particularly detailed errors; nearly every feature/permission system I have implemented did. However, it wouldn't be unusual for the full error to be wrapped or swallowed by some lazy error handling. Its a bit of a PITA but well worth it to translate to a safe and informative user facing error.

as a nit; RBAC is applied to an object based permissions system rather than being one. Simply, RBAC is a simplification of permission management in any underlying auth system.

replies(3): >>43528721 #>>43529190 #>>43531266 #
winwang ◴[31 Mar 25 00:12 UTC] No.43529190[source]▶
Slightly disagree at least for GCP. It will error with a detailed permission, but you're not just going to add that -- you're going to add a role (standard, unless you have custom roles), which you technically have to map back to the permission you need. But also, those (standard) roles have many permissions in one, so you likely overprovision (though presumably by just a bit).

...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

replies(2): >>43530688 #>>43531312 #
1. valenterry ◴[31 Mar 25 05:11 UTC] No.43531312[source]▶
> you're going to add a role (standard, unless you have custom roles), which you technically have to map back to the permission you need

Which is terrible btw. You dont "technicall" have to do that, you really cannot add roles to custom roles, you can only add permissions to custom roles. Which makes it really hard to maintain the correctness of custom roles since their permissions can and do change.

> ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

GCP even has something like that, but I honestly think that standard roles are usually fine. Sometimes making things too fine grained is not good either. Semantics matter.