Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public secrets exposure leads to supply chain attack on GitHub CodeQL

praetorian.com

Post reply on HN
Print view View original

41–50 of 66 posts

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

#41

Post by da_chicken »

winwang wrote: post #30
Normal_gaussian wrote: post #17

Earlier quoted context omitted.

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

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

> ...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 things this month. And what happens when one of the systems involves a third party?

Really, the need is to be able to provision access after the relationship is established. It's weird that you need a completely new secret to change access. Imagine if this were Linux and in order to access a directory you had to provision a new user to do it? How narrow do you really think user security access would be in practical terms then?

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

#42

Post by donavanm »

8note wrote: post #23
Normal_gaussian wrote: post #17

Earlier quoted context omitted.

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

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 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.

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

#43

Post by Elucalidavah »

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.

> For their fix, they disabled debug logs

For their quick fix, hopefully not for their final fix.

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

#44

Post by donavanm »

hobs wrote: post #27
milch wrote: post #24

Earlier quoted context omitted.

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

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.

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.

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

#45

Post by ashishb »

mdaniel wrote: post #40
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 area is near and dear to my heart, and I would offer that the solution isn't to decouple CD over into its own special little thing but rather to make the CD "multi factor" in that it must be "sub":"repo:octo-org/octo-repo:environment:prod"[1] and feel free to sprinkle in any other [fun claims][] you'd like to harden that system 1: https://docs.github.com/en/actions/security-for-github-actio... fun claims: https:…

Doable but I would prefer a complete isolation for simplicity.

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

#46

Post by raverbashing »

Normal_gaussian wrote: post #17
setr wrote: post #14

Earlier quoted context omitted.

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

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

But obviously then the security people will raise ruckus about any attempt of telling you what is wrong

(Which ok, for an external facing system is ok)

I can bet the huge prevalence of "system says no, and nothing tells you why" helps a lot with creating vulnerable systems.

System need an "let X person do Action" instead of having people waddle through 10 options like SystemAdminActionAllow that don't mean anything to an end user

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

#47

Post by valenterry »

winwang wrote: post #30
Normal_gaussian wrote: post #17

Earlier quoted context omitted.

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

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

> 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.

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

#49

Post by Sytten »

An again this would not be so bad an impact if github finally pushed their immutable actions [1]. I sound like a broken record since I keep repeating that this would solve like 70%+ of the scope of attacks on gha today. You would think that the weekly disaster they have would finally make them launch it.

[1] https://github.com/features/preview/immutable-actions

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

#50

Post by thund »

Sytten wrote: post #49

An again this would not be so bad an impact if github finally pushed their immutable actions [1]. I sound like a broken record since I keep repeating that this would solve like 70%+ of the scope of attacks on gha today. You would think that the weekly disaster they have would finally make them launch it. [1] https://github.com/features/preview/immutable-actions

They probably have good reasons if it's still in preview, that could be serious bugs, security gaps, potential breaking changes that would cause more harm than good if rushed, etc
Post reply on HN