Shellshock: The 22-Year-Old Bash Bug (CVE-2014-6271)
September 2014 | CVSS 10.0 – Critical
What Happened
For 22 years, a critical vulnerability sat in Bash – the default shell on virtually every Linux and Unix system. Every web server, every embedded device, every router.
Then Stéphane Chazelas found it in September 2014.
The vulnerability got dubbed Shellshock, and it let attackers execute arbitrary commands via environment variables. No authentication needed. No user interaction.
Just send a crafted HTTP request to a CGI script, and you owned the server.
The Vulnerability Explained
Bash has a feature: you can define functions in environment variables.
bash
export myfunc='() { echo "hello"; }'
The problem?Bash’s parser had a bug. After the function definition, it would keep parsing and executing anything that followed.
bash
export x='() { :;}; vulnerable'
When Bash starts and processes this environment variable:
1. It sees the function x
2. It sees :; (a no-op command)
3. It keeps going past the function definition
4. vulnerable gets executed
That’s the bug. Defining a function shouldn’t execute code after the definition. But it did.
How Attackers Exploited It
CGI Scripts (The Big One)
Apache web servers running CGI scripts were the primary vector. CGI (Common Gateway Interface) passes HTTP headers as environment variables.
Attack via User-Agent header:
bash
curl -H "User-Agent: () { :; }; /bin/bash -c 'cat /etc/passwd'" \
http://target.com/cgi-bin/vulnerable-script.cgi
Let’s break this down:
– () { :; }; – Define an empty function
– /bin/bash -c 'cat /etc/passwd' – Command after the function definition
– When CGI runs, Bash processes the environment
– The command executes
Other Attack Vectors
SSH with ForceCommand:
bash
ssh user@target "() { :; }; /bin/bash -c '...'"
DHCP client (yes, really):
Some systems passed DHCP responses to Bash scripts. A malicious DHCP server could own connecting clients.
Git commits:
Git hooks sometimes processed untrusted input through Bash.
Why It Was So Bad
Bash is everywhere:
- Every Linux server
- Every Mac (OS X uses Bash)
- Network routers
- IoT devices
- Embedded systems
- Cloud instances
And environment variables are everywhere:
- CGI scripts (Apache, nginx)
- SSH sessions
- DHCP responses
- Build systems
- Scheduled tasks (cron)
The combination was devastating.
Detection Commands
“`bash
Check if your Bash is vulnerable
env x='() { :;}; echo vulnerable’ bash -c “echo test”
If you see “vulnerable” followed by “test”, you’re affected
Check version
bash –version
Vulnerable: Bash 1.14 through 4.3
Fixed: Bash 4.3 patch 25+
“`
Remediation
Update Bash Immediately
“`bash
Debian/Ubuntu
sudo apt-get update
sudo apt-get –only-upgrade install bash
RHEL/CentOS
sudo yum update bash
macOS
Software Update (Apple released patch quickly)
Check if fixed
env x='() { :;}; echo vulnerable’ bash -c “echo test”
Should ONLY print “test”, NOT “vulnerable”
“`
Workarounds (If Patching Isn’t Immediate)
Disable CGI scripts:
“`apache
Apache – disable CGI
Comment out or remove ScriptAlias directives
Or use mod_security to block malicious patterns
“`
Firewall rules:
“`bash
Block suspicious User-Agent patterns (imperfect)
Look for “() {” in requests
“`
The Bigger Picture
Shellshock revealed something uncomfortable:
Core Unix tools had never been properly audited.
Bash had existed since 1989. For 22 years, this bug sat there. Anyone could have found it. But no one did – or if they did, they didn’t report it.
The vulnerability existed in:
– Function definition parsing
– Environment variable handling
– A fundamental Bash feature dating back decades
It made security researchers ask: What else is lurking in foundational software?
Timeline
| Date | Event |
|——|——-|
| 1989 | Bash created with the vulnerable code |
| Sep 24, 2014 | Bug privately reported|
| Sep 24, 2014 | Patches released |
| Sep 25, 2014 | Public disclosure |
| Sep 25, 2014 | Exploits seen in the wild within hours |
| Sep 26, 2014 | CVE-2014-7169 discovered (related bug) |
| Oct 2014 | Additional Bash vulnerabilities found |
Lessons Learned
- Old code accumulates bugs – Bash had this for 22 years
- Parser bugs are dangerous – Especially in shells
- Environment variables are attack surface – Who thinks about
env? - Peripheral attacks matter – CGI seems harmless until it isn’t
- Patch everything – Not just application code
Shellshock’s Legacy
After Shellshock:
- Major security audits of GNU tools
- Increased focus on “boring” infrastructure
- Shell hardening guides
- Static analysis of shell parsers
- CPS (Certificate in Practicing Security) questions about it
The vulnerability that needed no exploit. Just a malformed environment variable. The simplicity was the terror.
