DEV Community: François Best

[Boost]

François Best — Tue, 03 Dec 2024 23:33:15 +0000

Managing search parameters in Next.js with nuqs

Megan Lee for LogRocket ・ Dec 2

The Security of GitHub Actions

François Best — Mon, 24 Feb 2020 14:03:27 +0000

This article was originally posted on my blog - The Security of GitHub Actions.

GitHub Actions are a great way to build powerful customised CI/CD workflows using the power of community-driven resources, but they can be tricky to get right in terms of security.

Remote Code Execution as a Service

What GitHub gave us with Actions is basically the opportunity to run (almost) any code on their servers. This makes for a large attack surface and lengthy discussions, so let me define some boundaries.

This article is not about the kind of security regarding attacks against GitHub, but rather against yourself, when implementing a workflow.

It will also not consider GitHub itself as an adversary, and instead focus on threats coming from compromised third party actions and their impact on our workflows.

Attack Vectors

There are a few bad things that can happen to your workflow:

1. Data Theft

A malicious action leaks/steals your API tokens or other secrets required by legitimate actions.

2. Data Integrity Breaches

A malicious action modifies one of your built artefacts, injecting it with malicious code or corrupting it before it is processed or deployed by a legitimate action.

3. Availability

A malicious action crashes on purpose to prevent your workflow from executing successfully.

The Blessings & Curse of the Community

Having people work on their own actions and contributing them back to the community is definitely a blessing, as can be seen with the flourishing of the JavaScript ecosystem through NPM in the last decade.

But it comes with its woes, as we have seen in the past. Some famous examples being the leftPad incident (an availability "attack"), the attacks on ESLint that leaked credentials (data theft) or the event-stream attack that targeted Copay's build process (data integrity).

I guess every popular system will gather the interest of attackers, and in the end the benefits will probably outweigh the risks, as long as some protections are in place. Some are in the hands of GitHub (scanning and removing malicious actions), but some are in the hands of the users.

So what can you do to protect yourself ?

There has been some research by Julien Renaux on this topic, where he recommends pinning action versions not by Git tags, but by Git SHA-1, which is immutable.

This article builds on top of this research, looking specifically at actions using Docker and environment variables.

Docker-based Actions

Actions can run in a Docker container, created from an image pulled from Docker hub or GitHub's Image Registry. You can specify a tag to use for the image, but just like Git tags, Docker tags are not immutable.

As an example, I have created a small Node.js image:

# Dockerfile
FROM mhart/alpine-node:slim-12

CMD node -e 'console.log("hello")'

$ docker build -t franky47/test:foo .
$ docker push franky47/test:foo
foo: digest: sha256:0916addef9806b26b46f685028e8d95d4c37e7ed8e6274b822797e90ae6fd88f size: 740
$ docker run --rm -it franky47/test:foo
hello

Later on, I modify the image, rebuild and upload it using the same tag:

# Dockerfile
FROM mhart/alpine-node:slim-12

CMD node -e 'console.log("evil")'

$ docker build -t franky47/test:foo .
$ docker push franky47/test:foo
foo: digest: sha256:85fe141a80820b9db0631252ca4e06cc3ced6f662c540b9c25da645168ae5be7 size: 740
$ docker run --rm -it franky47/test:foo
evil

You can see how the tag transparently allows the evil version to run. The only defence against that is, just like Git, to use the SHA-256 digest hash to pin the image:

$ docker run --rm -it franky47/test@sha256:0916addef9806b26b46f685028e8d95d4c37e7ed8e6274b822797e90ae6fd88f
hello
$ docker run --rm -it franky47/test@sha256:85fe141a80820b9db0631252ca4e06cc3ced6f662c540b9c25da645168ae5be7
evil

Docker for Action Authors

Action authors can use Docker too. They add their Dockerfile to the action repository, and tell GitHub where to find it in the action.yml metadata file. Most of the time, the job runner will build the Docker image from the sources before running it onto the workflow.

Because those images are built out-of-band before the workflow runs, it's less likely that the Docker build context gets injected with malicious files or environment variables to compromise the built image. However, because the Dockerfile and the rest of the action repository come from Git, SHA-1 pinning is still recommended to be sure of what is being built.

Performance vs Security

It seems wasteful to rebuild images for every workflow run that depends on a Docker-based action. The image may take a long time to build, and that time is taken from the usage limits of everyone who depends on your action, it slows their workflows down, and it generally wastes energy.

Once your action is stable, you can build and publish the Docker image, then pin it to your action.yml file by digest hash:

# action.yml
name: Some action
runs:
  using: docker
  image: docker://franky47/test@sha256:0916addef9806b26b46f685028e8d95d4c37e7ed8e6274b822797e90ae6fd88f

This way, the users of your action will pull the image from the Docker registry instead of building it.

The threat model for this kind of delivery method now shifts from your action's users to your own workflow (the one you use to build & deploy the Docker image). But it has a few advantages:

You can review and pin any action you may need to build the image
Your image cannot be compromised by being built outside of a boundary you control.

Note: the threat model of the Docker registry being compromised or untrusted is out of the scope of this article.

Keeping Up With Security Updates

So what about security updates ? If versions are pinned forever, we miss out on critical vulnerabilities being patched up in the actions we use, their dependencies and all the dependency graph.

Unfortunately for now, while security and maintenance updates of dependencies can be automated for action authors, action users have to manually check and update their actions, and remember to pin the SHA-1 hash every time.

Services like Dependabot will eventually become able to analyse the dependency tree of a workflow file, make sure with CodeQL that it is free of known vulnerabilities or malicious code, and suggest updates back to the workflow file, hopefully in the form of SHA-1 pinnings.

Regardless of how you provide your action, there is another threat both action authors and consumers need to be aware of:

Environment Variables

GitHub Actions can communicate between one another through environment variables, in tandem with the I/O system that GitHub provides. It's considered a feature, but it has obvious security implications: any environment variable exported by an action will be part of the environment of all subsequent actions.

This means that any action that uses the environment should consider it potentially hostile. One example is the use of the environment for inputs when coupled with the fact that inputs can be optional.

Let's say an action defines its manifest as such:

# owner/repo/action.yml
name: An action
inputs:
  foo:
    required: false

When used, one can optionally pass an input for the foo argument:

# workflow.yml

- uses: owner/repo@deadf00d
  name: This action does not specify 'foo'
  # Here, foo = undefined
- uses: owner/repo@deadf00d
  name: This action specifies 'foo=bar'
  with:
    foo: bar
  # Here, foo = 'bar'

In the first call of the owner/repo action, the INPUT_FOO environment variable will not be defined, indicating to the action that the user did not specify an input for foo, asking to use the default value.

The second call specifies a value, so the action will see process.env.INPUT_FOO === 'bar'

But now if a malicious action inserts itself before those two actions, the first call will be vulnerable to injection:

# Yep, there's even an action to mutate the global environment:
- uses: allenevans/set-env@67961d8
  with:
    INPUT_FOO: evil
- uses: owner/repo@deadf00d
  name: This action does not specify 'foo'
  # Here, foo = 'evil'
- uses: owner/repo@deadf00d
  name: This action specifies 'foo=bar'
  with:
    foo: bar
  # Here, foo = 'bar'

The first call of owner/repo will think the input foo was set to evil, but the second call's explicit definition will take precedence.

Unfortunately, there seems to be no defence against that kind of behaviour, as there is no way to tell if an input environment variable comes from an explicit definition or from the global environment of the workflow.

I contacted GitHub on Hacker One regarding that matter, proposing that unspecified inputs be cleared of global values, their response was as follows:

"In an effort to make the CI environment as dynamic as possible,
we've decided to allow full access to the environment and have made the
strict security barrier lie at the ability to write to the workflow file."

Alternative Solution

Because the proposed solution would break existing behaviour, an alternative could be for GitHub to define an additional environment variable that lists the specified inputs, and to make this variable not injectable from the global environment. This way, actions that want to protect themselves could read from this variable, look for suspicious input variables and decide what to do.

Practicality of attacks

GitHub limiting their liability to attacks against the workflow files (a malicious maintainer modifying the workflow file in a sneaky pull request) is fair enough. However I believe there are other vectors in which an action can be compromised, without any GitHub involvement.

As demonstrated before, there are attacks on the NPM ecosystem, and a lot of actions use JavaScript because of the convenience it brings. A targeted attack on an action's dependency tree could go unnoticed if it activates only in the context of a specific workflow run.

Closing Notes

I think there is a market for automated action dependency analysis, where some services like Snyk can analyse workflows and report on vulnerabilities, suggest actions (pun intended) via pull requests and keep a close eye on malicious activity around GitHub Actions.

How to store E2EE keys in the browser

François Best — Fri, 13 Dec 2019 08:20:43 +0000

In end-to-end encrypted apps (E2EE), keys are generated in the client, and never sent to the server in clear-text.

It all usually starts from credentials provided by the user, such as username & password, which are derived into a strong cryptographic key using key-derivation functions :

Key derivation from master password using PBKDF2.

But where to store this key ? We can't reasonably ask the user to enter their credentials every time we need the key to encrypt/decrypt something, it would be a terrible UX and it would lead to users picking weaker passwords.

Let's have a look at what some E2EE apps do, by analyzing the ProtonMail approach.

Key Lifetime

The first thing to define is the lifetime of the key. For browser-based applications, keys usually last as long as the session.

This rules out localStorage, Indexed DB and cookies, but we could use sessionStorage, or simply keep it in memory only.

Persistence & Page Reloads

Keeping the key in memory has a serious downside: if your user ever reloads the page, the key is gone, and you would have to show a login screen again. Some E2EE apps like Bitwarden do this for extra security.

If we want our key to survive page reloads, we need to use some form of storage.

One thing to know however, is that most browsers will write the contents of sessionStorage to disk when reloading the page.

This is an issue as we don't want the key to leak, and any write to the filesystem places it outside of our control.

Divide to Conquer

The approach taken by ProtonMail is to split the key into two parts, store each part using different techniques, and recompose the key on page load.

To split the key, it is XORed with a buffer of random bytes. A copy of the original random data is going to be the other part, so that both of them individually are random, but by XORing them together, the randomness cancels out and reveals the key:

# Split
    a = key ^ random
    b = random

# Recompose
    a ^ b
 => (key ^ random) ^ random
 => key ^ (random ^ random) 
 => key ^ 0
 => key

One part is sent to sessionStorage, and the other uses a trick discovered by Thomas Frank named SessionVars.

`window.name`

There is a name property on the global window object in the browser. Its value persists across page reloads, but is not written to disk.

It has been used for cross-domain communications, and because other domains can see its value, we can't send anything there in clear text.

Fortunately, other domains can't access our domain's sessionStorage, so all they would see in window.name is random data.

The Right Amount of Persistence

The key does not need to be saved in those locations at all times however.

Because window.name is writable by everyone, it would be easy for attackers to erase the key if it was stored there as a single source of truth.

Instead, we can keep the key in memory, and only persist the key to those shared locations when the memory will be destroyed: on page unloads.

If the user reloaded the page, both parts of the key will be preserved and reassembled on page load, but if they simply closed the tab/window, both parts will be erased by the browser (end of the session).

Cleaning up

Now our key has been recomposed, both storage locations can be cleared as we don't want our horcruxes to be left around.

The original implementation of this system is available in ProtonMail's shared library.

Introducing `session-keystore`

For all to use this key storage technique without depending on ProtonMail's internal library, I built session-keystore, a TypeScript implementation with a few extra features:

Key expiration dates
Multiple stores
Key access/modification/expiration callbacks for monitoring
React hook (coming soon in a separate package)

Thanks for reading !

Follow me here or on Twitter for more E2EE & TypeScript content.