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

51–60 of 66 posts

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

#51

Post by thund »

ashishb wrote: post #45
mdaniel wrote: post #40

Earlier quoted context omitted.

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.

there are ways to isolate code from CI from CD, it's just not as easy as setting up the classic repo. One can use multiple repos for example, or run CI and CD with different products.

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

#52

Post by intelVISA »

thund wrote: post #50
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

Too much stakeholder alignment?

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

#53

Post by the8472 »

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…

Even AWS itself does better than this, but only on some services. They send an encrypted error which you can then decrypt with admin permissions to get those details.

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

#54

Post by timewizard »

Aeolun wrote: post #29
timewizard wrote: post #22

Earlier quoted context omitted.

> Perfect security does not exist. Having your CI/CD pipeline and your git repository service be so tightly bound creates security implications that do not need to exist. Further half the point of physical security is tamper evidence. Something entirely lost here.

I find that this is always easy to say from the perspective of the security team. Sure, it would be more secure to develop like that, but also tons more painful for both dev and user.

I don't code anymore. I like making devs suffer. And this is all good for the user. ;)

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

#55

Post by tanepiper »

intelVISA wrote: post #52
thund wrote: post #50

Earlier quoted context omitted.

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

Too much stakeholder alignment?

More like last year they laid off a whole bunch of people. We've been waiting for several open tickets on GitHub to be picked up, some were but seem to be abandoned and others just ignored.

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

#56

Post by arccy »

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.

just goes to show how lax microsoft is about their security. nobody should trust them.

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

#57

Post by 1oooqooq »

thund wrote: post #50
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

the only reason any company does or don't anything: not required for sales.

in 2019 i saw a fortune500 tech company put in place their own vulnerability scanner internal application which included this feature for our enterprise github repos. the tool was built and deployed to an old Linux docker image that was never updated to not be the target of the attack they were preventing... they never vetted to random version they started with either. i guess one can still use zip bomb or even the xz backdoor for extra irony points when attacking that system.

anyway, the people signing github checks also get promoted by pretending to implement that feature internally.

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

#58

Post by Uvix »

setr wrote: post #14
declan_roberts wrote: post #12

Earlier quoted context omitted.

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.

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

Azure’s RBAC system usually tells you this, at least when accessing the Azure management APIs. (Other APIs using RBAC, like the Azure Storage or Key Vailt ones, usually aren’t so accommodating. At least by their nature there’s usually only a handful of possible permissions to choose from.)

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

#59

Post by winwang »

da_chicken wrote: post #41
winwang wrote: post #30

Earlier quoted context omitted.

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

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

#60

Post by beaugunderson »

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.

Temporary action tokens have full write by default; you have to explicitly opt for a read-only version.

    > Read and write permissions
    > Workflows have read and write permissions in the repository for all scopes.
If you read this line of the documentation (https://docs.github.com/en/actions/security-for-github-actio...) you might think otherwise:

    > If the default permissions for the GITHUB_TOKEN are restrictive, you may have to elevate the permissions to allow some actions and commands to run successfully.
But I can confirm that in our GitHub organization "Read and write permissions" was the default, and thus that line of documentation makes no sense.
Post reply on HN