Skip to content

GitHub registration tokens potentially exposed in workflows

Moderate
npalm published GHSA-c7m9-5vcx-35m6 Oct 11, 2022

Package

terraform philips-labs/terraform-aws-github-runner (terraform)

Affected versions

< v1.12.0

Patched versions

1.12.0

Description

Impact

Users of this self-hosted module (used with standard) setting can potentially access the GitHub provided token to register a self-hosted runner. Repositories in the Org using runners deployed with this module could find the token via log file or process core dump. And next use the token to register their own runner to the Org. Nothing will be exposed outside the org as long only used internal. Impacts only the linux based runners and examples.

Temporary GitHub runner registration token (valid 30 minutes) is exposed in at least the situations

  • via user-data log: Using the module in non-ephemeral mode with provided user-data (cloud init) scripts for Linux.
  • core dump: side effect of running the GitHub runner agent provided config.sh script, which requires the token. As long the user can access the memory there is a potential case the token can obtained.

Patches

Module is patched to disable cloud-init logs by defaults all executed commands. A changed is made to ensure the config.sh scripts terminates. However, the default examples do not provide hardened examples, and block root access via sudo. Option to grep details from memory remain. The only option to avoid the token could leaked would be a one-time token or an option to invalidate. Currently GitHub does not provide any option for this. Also consider harden the AMI and avoid users can sudo, this could cause problems when running docker.

Workarounds

The GitHub registration token is exposed by logging. And the way the process for an ephemeral runner is started. The provided user_data script can be overwritten, or a custom AMI can be used to avoid the exposure via the defaults in module. The exposure of the token in the logging is caused by the way Amazon runs user-data (cloud init) by default. It seems the debug flag is disabled. By update the user-data script in the AMI template an disable the debug flag (set x+) logging of the token can be avoided.

References

Risk of core dump reported by Adwiteeya Agrawal (HashiCorp)

For more information

If you have any questions or comments about this advisory:

Update

Since versione 4.x one-time tokens can be used (JIT). Using a JIT token will avoid a token that can be reused is exposured to the runner.

Severity

Moderate

CVE ID

No known CVE

Weaknesses

No CWEs

Credits