←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.205s | 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 #
donavanm ◴[31 Mar 25 04:24 UTC] No.43531002[source]▶
This is intentional. You, the caller, get a generic http 400 “resource does not exist or are not authorized” response and message. Providing additional information about resource existence or permissions opens an entire category of information disclosure, resource discovery, attribute enumeration, policy enumeration problems.

The IAM admin persona is the one who gets a bunch of additional information. Thats accessible through aws iam policy builder, access logs, etc.

And no, its not feasible to determine if the initial caller is an appropriate iam admin persona and vary the initial response.

replies(2): >>43532459 #>>43542685 #
Atotalnoob ◴[01 Apr 25 03:55 UTC] No.43542685[source]▶
Just add this to the end of the error message “If this resource exists, you will need to add permission X. “
replies(1): >>43556567 #
1. donavanm ◴[02 Apr 25 13:40 UTC] No.43556567[source]▶
A late reply, but thats not how AWS IAM (or most advanced authz systems) work. AWS IAM is a “capability” system with dynamic policies; its nothing so simple as a “role” based authorization contrary to some product naming. To wit, every authz evaluation is a dynamic evaluation of policy and context. Each check uses one or more policies with one or more policy statements that are combined with some boolean logic and predicate rules. The policies may be associated (sourced) with the particular request based on calling principal, principal attributes, the target resource, a related resource, or even other metadata like AWS Org membership. Thats combined with the point in time context from the request (ex action name, parameters), request metadata (eg time), principal (id, tags, etc), resource (arn, attributes, tags), and some more “system” specific context variables. You (and the authorizing service) need ALL of that information to perform an authz evaluation.

This is complicated by dynamic data, like time or source address or caller principal tag values, so even identical requests may have different results. There are also complications like DENY statements and “unless” predicates that entirely defeat a simple “resource x requires y” approach.

Evem if you solve all of those challenges via magic you end up back at information disclosure where your adversary is now capable of rapidly enumerating and testing all your authz policies!