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

1. Old code accumulates bugs – Bash had this for 22 years
2. Parser bugs are dangerous – Especially in shells
3. Environment variables are attack surface – Who thinks about env?
4. Peripheral attacks matter – CGI seems harmless until it isn’t
5. 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.

Resources

• Red Hat Security Advisory
• NVD CVE-2014-6271
• Shellshock Attack Examples