Sandbox99 Chronicles

Reading Time: 3 minutes

Introduction

Environment variables are a foundational concept in POSIX-compliant operating systems such as Linux and macOS. Despite their simplicity, they play a critical role in system behavior, script execution, application configuration, and—most importantly—security.

As a seasoned security researcher, I’ve encountered multiple cases where a seemingly harmless environment variable introduced a serious vulnerability or broke an entire deployment. In this post, we’ll dive deep into how these variables work, how to manage them correctly, and how to avoid common security pitfalls—especially for IT professionals handling servers, automation, and shell environments.

💡 What Are Environment Variables?

Environment variables are key-value pairs that define configuration values accessible to user sessions and processes. They help define the operating context for your terminal, applications, and scripts.

They can influence everything from what shell you use to where programs look for executable files, and they are inherited by child processes unless overridden.

PATH=/usr/local/bin:/usr/bin:/bin
HOME=/home/sandbox

🛠️ Commonly Used Environment Variables

Variable	Description
PATH	Directories the shell searches for commands
HOME	User’s home directory
USER	Logged-in username
SHELL	User’s default shell
EDITOR	Default command-line text editor
LANG	Default locale/language setting
TMPDIR	Directory used for temporary files
LD_LIBRARY_PATH	Path for dynamic linker to search shared libraries (⚠️ High security impact)

Also worth noting are shell prompt-related variables like PS1, and history/logging variables like HISTFILE.

🔐 Security Implications of Environment Variables

Environment variables are often overlooked from a security perspective, but they’re a known attack surface. A few examples:

1. Privilege Escalation Risks

Misconfigured environment variables in cron jobs or sudo-elevated scripts can be exploited. For example:

LD_PRELOAD=/path/to/malicious.so some-command

2. Shellshock Vulnerability

Last 2014 exploit allowed remote code execution through crafted environment variable values when passed to a vulnerable version of bash.

3. Leaking Secrets

Exposing credentials through variables like AWS_SECRET_ACCESS_KEY, DATABASE_URL, or API_TOKEN is dangerous—especially if:

• Shell history is saved.
• Logs inadvertently include env output.
• Files are accidentally committed to version control.

4. Untrusted Inheritance

A child process inherits all parent variables, which may result in unintentional privilege or data exposure if not sanitized properly.

💻 Managing Environment Variables

Set Temporarily (Session Only)

export VAR_NAME="value"

Set Permanently (User-Level)

Add to: ~/.bashrc, ~/.zshrc, ~/.profile

export PATH="$HOME/.local/bin:$PATH"

Unset Variable

unset VAR_NAME

List Environment Variable

printenv
env
declare -p

🔍 Searching Environment Variables

This is a very common and powerful combination on the command line. You can use it to find specific environment variables without having to sift through a long list of all of them.

Here are the most common ways to do this, along with an explanation of the commands involved:

The Commands

• env: This command displays a list of all exported environment variables. These are the variables that are available to any programs you run from your current shell.
• printenv: This command is similar to env and is the officially recommended way to list all environment variables. It has some subtle differences in its behavior and options, but for most use cases, the output is identical to env.
• grep: This is a powerful command-line utility for searching plain-text data sets for lines that match a regular expression.
• | (The pipe operator): This is the key to connecting the two commands. The pipe takes the standard output of the command on its left (env or printenv) and uses it as the standard input for the command on its right (grep).

How to Use Them Together

The most common syntax is:

printenv | grep "pattern"
env | grep "pattern"

🧠 Advanced Usage

In Scripts

You can inject dynamic values into scripts using variables:

#!/bin/bash
echo "Welcome, $USER!"

Using .env Files

Common in DevOps pipelines and containerized apps. Example:

DATABASE_URL=postgres://user:pass@localhost:5432/db

Use source .env or dotenv tools to load them.

Subshell Behavior

(export VAR=value; some_command)  # Only exists in the subshell

🐚 Shell Differences

• Bash: Most common shell; supports functions, arrays, and .bashrc, .bash_profile
• Zsh: Popular among power users; more advanced scripting
• Fish: User-friendly, not POSIX-compliant
• macOS: Uses zsh by default (since Catalina), and GUI apps do not inherit terminal shell variables without workarounds (launchctl or ~/.MacOSX/environment.plist, now deprecated)

🐳 Environment Variables in Containers and CI/CD

Docker

– Define at build time with ENV
– Override at runtime with --env or .env

Example Dockerfile:

ENV APP_ENV=production

CI/CD Pipelines

CI systems like GitLab and GitHub Actions rely heavily on environment variables to pass secrets and configuration.

Security Risks:

• Printing variables in logs
• Poor secrets hygiene
• Global access without scoping

Best Practice: Use CI secrets or vault tools to inject values securely without exposing them to logs or command output.

✅ Best Practices for IT Professionals

✔ Avoid hardcoding sensitive values in environment variables
✔ Use dedicated secrets management tools (Vault, 1Password CLI, AWS Secrets Manager)
✔ Sanitize the environment when running scheduled jobs or scripts
✔ Protect .env files with .gitignore
✔ Regularly audit exported values (env | grep -i pass)
✔ Don’t rely on environment variables for long-term secrets storage

🧠 Final Thoughts

Environment variables are deceptively simple. For seasoned IT professionals and security-aware engineers, they’re not just conveniences—they’re critical configuration surfaces.

Understanding them allows for:

• Secure scripting
• Robust automation
• Cleaner deployment
• Reduced risk of secret leakage

Handle them with the same discipline you’d give to any configuration or credential management system.