Resolve 3rd party action security hole

frozenfrank commented 3 weeks ago

Overview

In class, @leesjensen has warned us about the dangers of using 3rd party actions. There is a potential threat that they could update their code to exfiltrate our CI secrets or perform other nefarious actions within our secure context.

Observation

ncipollo/release-action@v1 is in the form <GITHUB_USERNAME>/<REPO_NAME>@SHA (see Using tags for [actions] version management).

In this case, v1 is a tag which resolves to a commit.

Resolution

Fix the full 40 digit SHA to use from the 3rd party action...

The 'v1' that existed before is a tag which resolves to a SHA.
This works in industry to get the right version, but a bad actor
could still reassign that tag to a different commit potentially
containing nefarious code.

By assigning the full 40 digit SHA, we prevent this kind of attack.
Tests that attempt to create a 40 digit tag (nefariously) pointing
to a different commit are foiled. The 'git' system directly uses
the commit with the full name rather than the tag.

Interestingly, this tag-redirection attack does work on abbreviated
SHAs. If a particular commit is prefixed with 0a00a74, creating a tag
with that same name does misdirect the system when performing a
'git checkout'. For this purpose, we specify the entire 40 digit SHA.

Correctness

This change was tested and was verified to work. See this workflow run #12 where the change existed and the jobs all passed.

leesjensen commented 3 weeks ago

Maybe we should use the action created by GitHub even though it is not maintained. I believe it is the base for the action that we are currently suggesting.

https://github.com/actions/create-release

frozenfrank commented 1 week ago

Maybe we should use the action created by GitHub even though it is not maintained. I believe it is the base for the action that we are currently suggesting.

https://github.com/actions/create-release

@leesjensen That sounds like a great idea. We are not using any fancy, bleeding edge features of the action, and we do not need to rely on anyone to maintain the action.

While I don't know the man personally, I do see that the ncipollo/release-action repository is one of the 4 endorsed by the surviving official GitHub action. For me, the official endorsement gives me sufficient confidence to trust in the author, but I understand why that is a general concern.

Maintained Actions:

elgohr/Github-Release-Action

marvinpinto/action-automatic-releases

softprops/action-gh-release

ncipollo/release-action

Source: actions/create-release

frozenfrank commented 1 week ago

Update

I looked in to it more and used the unmaintained version of actions/create-release in my repository.

Logs

Here are the relevant runner logs:

Conclusion

The action is definitely not maintained, and I would not recommend using it for the following reasons:

It requires a lower-level interface to call the method
- Requires manually passing in GITHUB_TOKEN via an environment variable
It relies on an outdated version of node (node12) which will soon be deprecated
It relies on a soon to be removed feature called set-output

The runtime warnings are just not worth it. The features may disappear at any time and (randomly) cause the workflow to stop working.

Recommendation

Continue using the ncipollo action which is officially endorsed by the actions/create-release repo.

devops329 / devops