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

Bypassing GitHub Actions policies in the dumbest way possible

blog.yossarian.net

Post reply on HN
Print view View original

101–110 of 129 posts

Re: Bypassing GitHub Actions policies in the dumbest way possible

#101

Post by rainonmoon »

lelandbatey wrote: post #82
xmprt wrote: post #76

Earlier quoted context omitted.

This is a strawman argument. If a developer writes code that does something malicious then it's on the developer. If they install a program then the accountability is a bit fuzzier. It's partly on the developer, partly on security (for allowing an unprivileged user to do malicious/dangerous things even unknowingly), and partly on IT (for allowing the unauthorized program to run without any verification).

It's not a straw man, I'm not trying to defuse liability. Of course a developer running malicious code they wrote is responsible for the outcomes. I am pointing out that if every unique binary never before run/approved is blocked, then no developer will be able to build and then run the software they are paid to write, since them developing it modifies said software into a new and never before seen sequence of bits.…

It's a straw man in that you're establishing an inherently facile and ridiculous scenario just to knock it down. A scenario that, as others have demonstrated, is not grounded in any logical reality. "Nobody mentioned this imaginary horrible system I just thought of, but if they had, it sure would be terrible" is quite a hill to die on.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#102

Post by moooo99 »

welshwelsh wrote: post #70
kj4ips wrote: post #6

This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…

Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea. Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.

> Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.

This is a lovely take if your business exclusively running on FOSS on premise software, but is a receipe for some hefty bills from software vendors due to people violating licensing conditions

Re: Bypassing GitHub Actions policies in the dumbest way possible

#103

Post by akoboldfrying »

john-h-k wrote: post #64

There is no meaningful way to get around this. Ban them in `uses:` keys? Fine, they just put it in a bash script and run that. Etc etc. If it allows running arbitrary code, this will always exist

I agree that their proposed "fix" is not a fix at all, due to the fact that you can run arbitrary shell commands that achieve the same thing.

OTOH, if in addition to restricting to a whitelist of actions you completely forbid ad hoc shell commands (i.e., `run:` blocks), now you have something that can be made secure.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#104

Post by TheNewsIsHere »

lelandbatey wrote: post #82
xmprt wrote: post #76

Earlier quoted context omitted.

This is a strawman argument. If a developer writes code that does something malicious then it's on the developer. If they install a program then the accountability is a bit fuzzier. It's partly on the developer, partly on security (for allowing an unprivileged user to do malicious/dangerous things even unknowingly), and partly on IT (for allowing the unauthorized program to run without any verification).

It's not a straw man, I'm not trying to defuse liability. Of course a developer running malicious code they wrote is responsible for the outcomes. I am pointing out that if every unique binary never before run/approved is blocked, then no developer will be able to build and then run the software they are paid to write, since them developing it modifies said software into a new and never before seen sequence of bits.…

Your premise assumes there are policies and technologies in place that restrict what a developer can do.

This is often the case, although I’ve very rarely seen environments as restrictive as what you describe being enforced on developers.

Typically developer user accounts and assigned devices are in slightly less restrictive policy groupings, or are given access to some kind of remote build/test infrastructure.

Of course companies need the option to control what software is run on their infrastructure. There are an endless stream of reasons and examples for that. Up-thread there’s a great example of what happens when you let folks install Oracle software without guardrails. Businesses are of course larger and more complex than their developers and have needs beyond their developers.

What matters here is implementation and policy management. You want those to be balanced between audience needs and business needs.

It’s also worth mentioning that plenty of developers have no clue what they’re doing with computers outside their particular area of expertise.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#105

Post by OptionOfT »

wereHamster wrote: post #81
opello wrote: post #63

Earlier quoted context omitted.

Maybe there's a future Dependabot feature to create FYI issues when in use tags change?

securityscorecard is easy to integrate (it's a cli tool or you run it as a github action), one of the checks it performs is "Pinned-Dependencies": https://github.com/ossf/scorecard/blob/main/docs/checks.md#p... . Checks that fail generate an security alert under Security -> Code scanning.

Is it transitive?

> The check works by looking for unpinned dependencies in Dockerfiles, shell scripts, and GitHub workflows which are used during the build and release process of a project.

Does it detect an unpinned (eg a Docker tag) of a pinned dependency.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#106

Post by XCabbage »

I don't see the vulnerability. In fact, I think considering this a problem at all is ridiculous.

Obviously it's impossible to block all ways of "bypassing" the policy. If you are a developer who has already been entrusted with the ability to make your GitHub Actions workflows run arbitrary code, then OF COURSE you can make it run the code of some published action, even if it's just by manual copy and paste. This fact doesn't need documenting because it's trivially obvious that it could not possibly be any other way.

Nor does it follow from this that the existence of the policy and the limited automatic enforcement mechanism is pointless and harmful. Instead of thinking of the enforcement mechanism as a security control designed to outright prevent a malicious dev from including code from a malicious action, instead think of it more like a linting rule: its purpose is to help the developer by bringing the organisation's policy on third party actions to the dev's attention and pointing out that what they are trying to do breaks it.

If they decide to find a workaround at that point (which of course they CAN do, because there's no feasible way to constrain them from doing so), that's an insubordination issue, just like breaking any other policy. Unless his employer has planted a chip in his brain, an employee can also "bypass" the sexual harassment policy "in the dumbest way possible" - just walk up to Wendy from HR and squeeze her tits! There is literally no technical measure in place to make it physically impossible for him do so. Is the sexual harassment policy therefore also worse than nothing, and is it a problem that the lack of employee brain chips isn't documented?

Re: Bypassing GitHub Actions policies in the dumbest way possible

#107

Post by 1oooqooq »

hk1337 wrote: post #61
TheTaytay wrote: post #26

I don’t understand the risk honestly. Anyone who can write code to the repo can already do anything in GitHub actions. This security measure was never designed to mitigate against a developer doing something malicious. Whether they clone another action into the repo or write custom scripts themselves, I don’t see how GitHub’s measures could protect against that.

I haven't tested this but the main risk that is possible is users creating PRs on public repositories with actions that run on pull request.

if your unprotect pr job can have side effects besides accessing the public repo and returning a boolean for passing status, what hope is there?

Re: Bypassing GitHub Actions policies in the dumbest way possible

#108

Post by danudey »

OptionOfT wrote: post #54

We forked the actions as a submodule, and then pointed the uses to that directory. That way we were still tracking the individual commits which we approved as a team. Now there is interesting dichotomy. On one hand PMs want us to leverage GitHub Actions to build out stuff more quickly using pre-built blocks, but on the other hand security has no capacity or interest to whitelist actions (not to mention that the white…

You can sign images, and then theoretically validate those signatures; if an image changes it no longer matches the signature.

Optionally, you can tell your action to reference the docker image by sha256 hash also, in which case it's effectively immutable.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#109

Post by kstrauser »

janstice wrote: post #96
neilv wrote: post #72

Earlier quoted context omitted.

> Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement. I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this. One reason is that much of the software industry has become a batpoop-insane slimefest of privacy (IP) invasion, as well as grossly negligent s…

For example, if someone installs the wrong version of Oracle Java on a VM in our farm, the licencing cost is seven figures as they want to charge per core that it could conceivably run on - this would be career-limiting for a number of people at once.

Or VirtualBox’s extensions which make it usable. Those are free to download but could make you an audit target.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#110

Post by kstrauser »

zmgsabst wrote: post #98
lelandbatey wrote: post #74

Earlier quoted context omitted.

Developers are going to write code to do things for them, such as small utility programs for automating work. Each custom program is a potentially brand new binary, never sent before by the security auditing software. Does every program written by every dev have to be cleared? Is it best in such a system to get an interpreter cleared so I can use that to run whatever scripts I need?

Developers are generally given specific environments to run code, which aren’t their laptops — eg, VMs in a development environment. The goal isn’t to stop a developer from doing something malicious, but to add a step to the chain for hackers to do something malicious: they need to pwn the developer laptop from the devbox before they can pivot to, eg, internal data systems.

In my experience, that’s rare. Everywhere I’ve worked had devs working on code directly on their laptops.
Post reply on HN