
Use GitHub actions at your own risk - shprink
https://julienrenaux.fr/2019/12/20/github-actions-security-risk/
======
safaci2000
This also applies to most library, docker (as mentioned) and basically
anything you use that's 3rd party. I suppose it varies on your level of
paranoia, though honestly if you rely on a github action in your production
flow you should fork the project. Never mind doing something malicious, they
could just as easily delete the entire repo and now your critical feature you
needed to deliver are blocked because the library you were relying one has
disappeared.

Anything you use in a critical path you should control. If you're managing
your own fork, nobody will inject bad code except yourself.

Just my 2 cents. Also, the things that github 3rd party actions are doing is
usually not that complicated. I mean how many different ways can you publish a
docker image or deploy an artifact to S3. Once it works, it either works or
doesn't. It's not a programming library where optimizations are created or we
fixed a security vulnerability (though I suppose that can come up ).

Sorry minor rant. food for thought.

~~~
xeromal
Do you fork your own programming languages too?

~~~
amdelamar
Should fork the OS its running on too! /s

~~~
xeromal
Most def otherwise bad patches might ruin their production

------
miskander
My team and I work on Actions at GitHub and I just wanted to stop by and add a
bit more context. We definitely understand the concerns the article brings up
and it's actually why we recommend in our documentation using SHA references
when consuming third-party Actions. We also introduced the concept of verified
Actions that extend an Organization's verification to Actions in the
marketplace. We know there's more to do here to help prevent any malicious
Actions and we're planning to continue to iterate. Thanks so much for the
feedback and keep it coming.

~~~
dherman
I’m excited about Actions generally, so I’m glad to hear your team is aware of
the challenges of building a reliable ecosystem of third party dependencies by
reference to repos.

Still, recommending git SHAs has real ergonomic and maintainability issues,
and while it’s more defensive it doesn’t prevent left-pad style broken builds
due to disappearing content.

And at the same time, GitHub is investing heavily in package management
infrastructure. I don’t say this lightly because designing good dependency
management systems is much more subtle and difficult than people typically
recognize, but from where I sit this appears to be fundamentally a dependency
management concern. It seems a shame not to try to put GitHub Package Registry
to good work here. Is that something potentially on the horizon?

~~~
hn_throwaway_99
This is an excellent point, and should solve the issue I put below about
builds taking forever when pulling in a slow-building action.

If I'm using a marketplace action in my workflow, I want "foo/action@v1.0.0"
to be treated like a binary package dependency, not a build from sourcecode.

------
rgoldfinger
The same could be said for any use of docker images. Seems a little unfair to
single out Github.

~~~
reilly3000
That's definitely true, but given the sensitivity of having access to private
source and secrets I think its fair to call out a warning.

~~~
ericlewis
couldn't a malicious docker image also be tooled to dump all of that stuff to
an external destination?

~~~
reilly3000
Absolutely. CI systems tend to get broad access to everything sacred. Giving
that level of access to community code is risky in the least.

------
marcus_holmes
Sorry, that whole github actions concept gives me the screaming heeby-jeebies.

We're really not even pulling the dependency locally, we're just going to run
someone else's code from their repo, on github's server, with our data and
secrets?

What could possibly go wrong with that? /s

~~~
edaemon
This isn't much different than other CI/CD pipelines. Docker images come to
mind.

~~~
marcosdumay
This isn't much different than other _SaaS_ CI/CD pipelines.

~~~
jrochkind1
Right, such as travis, circleci, gitlab, etc. All of which are pretty popular,
so clearly there is interest in SaaS CI/CD.

~~~
marcosdumay
Yes, they are popular. But on-premises ones also exist, are popular too, and
mostly do not have this one problem.

It's a relevant distinction on this context.

------
bhouston
How does this different from any other hosted CI/CD solution?

I am thinking specifically about: * Gitlab's CI * CircleCI * TeamCity

etc....

~~~
boleary-gl
I think the main difference is actions is built around the idea of this
ecosystem of "just include other people's code in your pipeline." With Team
City or GitLab you're typically only running code you wrote in their
respective configuration files.

That's super valuable because you get started faster - e.g. "oh here's how I
can deploy a lambda" but brings up this security concern of running other
people's code. As discussed in the article, this is something NPM solved after
the left-pad debacle. And I am sure (I hope) that GitHub will either change
the documentation or add features to prevent this.

------
robbya
This is correct, using a commit hash is safer.

However, you'll sometimes want to update the commit hash after the action's
maintainer releases new code. If you don't then you run the risk of running an
old action that has vulnerable components or bugs.

The easiest workflow for that should be Dependabot's updater for GitHub
actions: [https://dependabot.com/github-
actions/](https://dependabot.com/github-actions/) Has anyone tried that
approach for GitHub actions?

You still need to review the action's code before you use it, and every time
you update to a new commit hash. But this approach protects you from
automatically running new malicious code pushed to master/re-tagged.

------
polymeris
> Each hash is supposed to be unique and you cannot rewrite history with the
> exact same SHA-1.

I thought SHA-1 wasn't considered secure?

~~~
breser
There are collision attacks against SHA-1. But the currently known collision
attacks aren't a big problem for git for a variety of reasons.

Git uses hashes that include more data than just the hash of the content of an
object. Meaning the existing known collisions don't work and you'd have to
develop collisions specifically to target git.

Additionally, the current known collision attacks require generating the two
colliding contents as a pair. You can't take an existing document and then
generate a collision for that document. Further, the technique is not
particularly good for text documents because you need to include some data to
force the collision. This is easily missed in binary documents but not the
text documents most people are committing into git repos (granted you can put
binary files into git and that would still work but the other reasons for this
not being very useful still apply).

Git also has code to deal with possible collisions and will fall back to full
comparison and will fail a commit that creates a collision. Finally,
generating these document pairs leaves detectable patterns in the content.
GitHub scans for these patterns as part of their process.

[https://github.blog/2017-03-20-sha-1-collision-detection-
on-...](https://github.blog/2017-03-20-sha-1-collision-detection-on-github-
com/)

~~~
namibj
You hand-wave the difference between collision resistance and second-preimage
resistance most away...

Just a recap: generating two files who's hashes collide takes 2^80 tries if
SHA-1 wasn't broken, whereas finding a file with the same hash as a specific,
externally-determined file takes 2^160 tries.

------
rattray
Title should be adjusted to mention branches & tags specifically.

------
hn_throwaway_99
I think GitHub is making it _extremely_ easy to make this mistake by making
the Actions Marketplace so easily accessible when you're editing a workflow in
their UI. This is horrible design. They should at least point out the real
consequences of pulling in these other actions and letting you fork right
there.

I mean, there is an action in the marketplace that runs git-crypt to decrypt
your files. With this issue, no user should _ever_ be using this action
without forking it to their repo first.

~~~
wizzwizz4
It's to reduce the friction to lock-in. GitHub should Just Work™, regardless
if that sacrifices security, because the smoother the experience the more
processes you'll build around it, so the harder it'll be to migrate away from
it.

------
nyxtom
Looks like you can now run actions on your own servers instead
[https://help.github.com/en/actions/automating-your-
workflow-...](https://help.github.com/en/actions/automating-your-workflow-
with-github-actions/hosting-your-own-runners) which might help with things
quite a bit considering that you shouldn't have to expose any secrets if you
are running them on your own machines

------
wildpeaks
One thing I'm missing from Actions is a way to manually trigger an action from
the UI.

Currently the closest equivalents are making a request via the API (but then
you need a token with it, and all the security concerns it opens) or sending a
special message using an empty commit (but I haven't found a simple way to do
that from inside VSCode, unless I missed it somewhere).

------
unlinked_dll
if you're going to use memes in a blog post at least use them correctly

~~~
shprink
What meme would you use then?

~~~
unlinked_dll
Instead of an incorrectly applied tapping head meme I would have used the Big
Brain meme to sarcastically suggest that using a package’s reported version on
the marketplace was smarter than a git SHA

------
bouke
I guess the same holds for Azure DevOps plugins, over which users don’t even
have control over the version used. So what’s preventing plugin owners from
doing something harmful?

------
paco_sinbad
What about hash collision? You could write an obfuscator to keep appending
useless code or comments to the payload to continually generate commit hashes
until you get a collision with the same original hash. A lot of work of
course, and the hash is so f-ing huge it might take a few thousand compute-
years, but you know, hackers find a way. If nothing else, use the full 40-char
hash to ensure that your attacker has to find the same atom twice across 10
moons.

