CVE-2023-51664

tj-actions/changed-files is a Github action to retrieve all files and directories. Prior to 41.0.0, the tj-actions/changed-files workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets. This issue may lead to arbitrary command execution in the GitHub Runner. This vulnerability has been addressed in version 41.0.0. Users are advised to upgrade.

tj-actions/changed-files is a Github action to retrieve all files and directories. Prior to 41.0.0, the tj-actions/changed-files workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets. This issue may lead to arbitrary command execution in the GitHub Runner. This vulnerability has been addressed in version 41.0.0. Users are advised to upgrade.

Summary

The tj-actions/changed-files workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets.

Details

The changed-files action returns a list of files changed in a commit or pull request which provides an escape_json input enabled by default, only escapes " for JSON values.

This could potentially allow filenames that contain special characters such as ; and ` (backtick) which can be used by an attacker to take over the GitHub Runner if the output value is used in a raw fashion (thus being directly replaced before execution) inside a run block. By running custom commands an attacker may be able to steal secrets such as GITHUB_TOKEN if triggered on other events than pull_request. For example on push.

Proof of Concept

1. Submit a pull request to a repository with a new file injecting a command. For example $(whoami).txt which is a valid filename.
2. Upon approval of the workflow (triggered by the pull request), the action will get executed and the malicious pull request filename will flow into the List all changed files step below.

      - name: List all changed files
        run: |
          for file in ${{ steps.changed-files.outputs.all_changed_files }}; do
            echo "$file was changed"
          done

Example output:

##[group]Run for file in $(whoami).txt; do
    for file in $(whoami).txt; do
        echo "$file was changed"
    done
shell: /usr/bin/bash -e {0}
##[endgroup]
runner.txt was changed

Impact

This issue may lead to arbitrary command execution in the GitHub Runner.

Resolution

• A new safe_output input would be enabled by default and return filename paths escaping special characters like ;, ` (backtick), $, (), etc for bash environments.

• A safe recommendation of using environment variables to store unsafe outputs.

- name: List all changed files
  env:
    ALL_CHANGED_FILES: ${{ steps.changed-files.outputs.all_changed_files }}
  run: |
    for file in "$ALL_CHANGED_FILES"; do
      echo "$file was changed"
    done

Resources

• Keeping your GitHub Actions and workflows secure Part 2: Untrusted input
• Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

tj-actions/changed-files is a Github action to retrieve all files and directories. Prior to 41.0.0, the tj-actions/changed-files workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets. This issue may lead to arbitrary command execution in the GitHub Runner. This vulnerability has been addressed in version 41.0.0. Users are advised to upgrade.

tj-actions/changed-files is a Github action to retrieve all files and directories. Prior to 41.0.0, the tj-actions/changed-files workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets. This issue may lead to arbitrary command execution in the GitHub Runner. This vulnerability has been addressed in version 41.0.0. Users are advised to upgrade.

Summary

The tj-actions/changed-files workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets.

Details

The changed-files action returns a list of files changed in a commit or pull request which provides an escape_json input enabled by default, only escapes " for JSON values.

This could potentially allow filenames that contain special characters such as ; and ` (backtick) which can be used by an attacker to take over the GitHub Runner if the output value is used in a raw fashion (thus being directly replaced before execution) inside a run block. By running custom commands an attacker may be able to steal secrets such as GITHUB_TOKEN if triggered on other events than pull_request. For example on push.

Proof of Concept

1. Submit a pull request to a repository with a new file injecting a command. For example $(whoami).txt which is a valid filename.
2. Upon approval of the workflow (triggered by the pull request), the action will get executed and the malicious pull request filename will flow into the List all changed files step below.

      - name: List all changed files
        run: |
          for file in ${{ steps.changed-files.outputs.all_changed_files }}; do
            echo "$file was changed"
          done

Example output:

##[group]Run for file in $(whoami).txt; do
    for file in $(whoami).txt; do
        echo "$file was changed"
    done
shell: /usr/bin/bash -e {0}
##[endgroup]
runner.txt was changed

Impact

This issue may lead to arbitrary command execution in the GitHub Runner.

Resolution

• A new safe_output input would be enabled by default and return filename paths escaping special characters like ;, ` (backtick), $, (), etc for bash environments.

• A safe recommendation of using environment variables to store unsafe outputs.

- name: List all changed files
  env:
    ALL_CHANGED_FILES: ${{ steps.changed-files.outputs.all_changed_files }}
  run: |
    for file in "$ALL_CHANGED_FILES"; do
      echo "$file was changed"
    done

Resources

• Keeping your GitHub Actions and workflows secure Part 2: Untrusted input
• Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests