Summary
Versions of step-security/harden-runner prior to v2.10.2 contain multiple command injection weaknesses via environment variables that could potentially be exploited under specific conditions. However, due to the current execution order of pre-steps in GitHub Actions and the placement of harden-runner as the first step in a job, the likelihood of exploitation is low as the Harden-Runner action reads the environment variable during the pre-step stage. There are no known exploits at this time.
Details
-
setup.ts:169 1 performs execSync with a command that gets
invoked after interpretation by the shell. This command includes an
interpolated process.env.USER variable, which an attacker could
modify (without actually creating a new user) to inject arbitrary
shell expressions into this execSync. This may or may not be likely
in practice, but I believe the hygienic way to perform the underlying
operation is to use execFileSync or similar and bypass the
underlying shell evaluation.
-
setup.ts:229 2 has a nearly identical execSync to (1) above,
but with $USER for shell-level interpolation rather than string
interpolation. However, this is still injectable and would be best
replaced by an execFileSync, per above.
-
arc-runner:40-44 3 has an execSync with multiple string
interpolations. Most of these do not appear immediately injectible
(since they appear to come from presumed trusted API responses), but
the expansion of getRunnerTempDir() may be injectable due to its
dependence on potentially attacker-controllable environment variables
(e.g. RUNNER_TEMP). The underlying operation appears to be a trivial
file copy, so this entire subprocess should in theory be replaceable
with ordinary NodeJS fs API calls instead.
-
arc-runner:53 4 demonstrates the same weakness, and has the same
resolution as (3).
-
arc-runner:57 demonstrates the same weakness as (3) and (4), and
has the same resolution.
-
arc-runner:61 demonstrates the same weakness as (3), (4), and (5),
and has the same resolution.
Acknowledgment
We thank @woodruffw for the thorough analysis, bringing these issues to our attention, and working with us on the fix.
woodruffw Reporter
Summary
Versions of step-security/harden-runner prior to v2.10.2 contain multiple command injection weaknesses via environment variables that could potentially be exploited under specific conditions. However, due to the current execution order of pre-steps in GitHub Actions and the placement of harden-runner as the first step in a job, the likelihood of exploitation is low as the Harden-Runner action reads the environment variable during the pre-step stage. There are no known exploits at this time.
Details
setup.ts:169 1 performs
execSyncwith a command that getsinvoked after interpretation by the shell. This command includes an
interpolated
process.env.USERvariable, which an attacker couldmodify (without actually creating a new user) to inject arbitrary
shell expressions into this
execSync. This may or may not be likelyin practice, but I believe the hygienic way to perform the underlying
operation is to use
execFileSyncor similar and bypass theunderlying shell evaluation.
setup.ts:229 2 has a nearly identical
execSyncto (1) above,but with
$USERfor shell-level interpolation rather than stringinterpolation. However, this is still injectable and would be best
replaced by an
execFileSync, per above.arc-runner:40-44 3 has an
execSyncwith multiple stringinterpolations. Most of these do not appear immediately injectible
(since they appear to come from presumed trusted API responses), but
the expansion of
getRunnerTempDir()may be injectable due to itsdependence on potentially attacker-controllable environment variables
(e.g.
RUNNER_TEMP). The underlying operation appears to be a trivialfile copy, so this entire subprocess should in theory be replaceable
with ordinary NodeJS
fsAPI calls instead.arc-runner:53 4 demonstrates the same weakness, and has the same
resolution as (3).
arc-runner:57 demonstrates the same weakness as (3) and (4), and
has the same resolution.
arc-runner:61 demonstrates the same weakness as (3), (4), and (5),
and has the same resolution.
Acknowledgment
We thank @woodruffw for the thorough analysis, bringing these issues to our attention, and working with us on the fix.