Public secrets exposure leads to supply chain attack on GitHub CodeQL • Hacker News Board

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#61

Post by Pathogen-David » Mon, Mar 31, 2025, 6:48 PM UTC

nyrikki wrote: post #6

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.

If the GitHub Actions temporary token does not have workflow-defined permissions scope, it defaults either to a permissive or restricted default scope based on the repository's setting. This setting can also be configured at the organization level to restrict all repos owned by the org.

Historically the only choice was permissive by default, so this is unfortunately the setting used by older organizations and repos.

When a new repo is created, the default is inherited from the parent organization, so this insecure default tends to stick around if nobody bothers to change it. (There is no user-wide setting, so new repos owned by a user will use the restricted default. I believe newly created orgs use the better default.)

[0]: https://docs.github.com/en/actions/security-for-github-actio...

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#62

Post by nrvn » Mon, Mar 31, 2025, 9:25 PM UTC

ashishb wrote: post #39

I am getting more and more convinced that CI and CD should be completely separate environments. Compromise of CI should not lead to token leaks related to CD.

This is essentially how separation of duties(and concerns) looks like. And this is how some of the good examples of projects work. Specific techniques and tooling and specific boundaries of CI and CD vary depending on the nature of the end product but conceptually you are absolutely right.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#63

Post by da_chicken » Tue, Apr 01, 2025, 3:00 AM UTC

winwang wrote: post #59

da_chicken wrote: post #41

Earlier quoted context omitted.

> ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep. The problem with that is that it can be difficult to know what you need, and it may be impossible to simulate in any practical sense. Like, sure, I can stand up a pair of test systems and fabricate every scenario I can possibly imagine, but my employer does want me to do other thing…

> the need is to be able to provision access after the relationship is established Could you go into more detail? At a base level interpretation, this is how it works already (you need a principal to provision access for...), but you presumably mean something more interesting?

With token-based access, you typically assign the role when the token is created. The access level the token has is typically locked at that point. If you're generating an API access token, you might specify the token is read-only. If you later decide that read/write access is needed, you need to generate a new token with the new access level and replace the token id and value in the client system.

It's not difficult, but it's a much bigger pain in the ass than just changing access or changing role on a user.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#64

Post by Atotalnoob » Tue, Apr 01, 2025, 3:55 AM UTC

donavanm wrote: post #42

8note wrote: post #23

Earlier quoted context omitted.

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.

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 accessibl…

Just add this to the end of the error message “If this resource exists, you will need to add permission X. “

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#65

Post by stogot » Tue, Apr 01, 2025, 10:45 AM UTC

nyrikki wrote: post #6

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.

The 2023 Microsoft hack (that CISA completely called them out for poor security) also was similar to this. Their blog post that tried to explain what happened left so many unanswered questions

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#66

Post by donavanm » Wed, Apr 02, 2025, 1:40 PM UTC

Atotalnoob wrote: post #64

donavanm wrote: post #42

Earlier quoted context omitted.

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 accessibl…

Just add this to the end of the error message “If this resource exists, you will need to add permission X. “

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!