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:
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
Patches
Module is patched to disable cloud-init logs by defaults all executed commands. A changed is made to ensure the
config.shscripts 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: