←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: 0s | 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 #
8note ◴[30 Mar 25 23:11 UTC] No.43528721[source]▶
ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.
replies(2): >>43528779 #>>43531002 #
milch ◴[30 Mar 25 23:19 UTC] No.43528779[source]▶
AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving account
replies(1): >>43528940 #
hobs ◴[30 Mar 25 23:37 UTC] No.43528940[source]▶
Right, you can go to cloudtrail and probably get it, but I have definitely ran into things like service says you do not have access to resource or it does not exist - randomly providing the account some other tangentially related permission magically fixes it, I've found sometimes trying the UI and the API will give different errors to help, and neither is particularly more useful than the others.
replies(3): >>43529250 #>>43529256 #>>43531059 #
1. donavanm ◴[31 Mar 25 04:32 UTC] No.43531059[source]▶
Look in to the AWS IAM “service description files” aka SDF. Thats exposed via the console Policy Builder or Policy Evaluator logic. The SDF _should_ encode all the context (eg resource attributes, principal metadat) that goes in to the authz decision. The most common opaque issue youll see is where one action has other required resources/actions. Eg a single action attaching an ebs volume requires permission on both instance and volume and _maybe_ kms key with permissions across those services.