StatewardStateward
← Toutes les vulnérabilités
CRITICALInfraexploited in the wildcurated

CVE-2014-6271

Linux · GNU Bash

Résumé

Shellshock, disclosed on 24 September 2014 (twelve days after Bash maintainer Chet Ramey was privately warned by its discoverer, Stephane Chazelas), was a 25-year-old flaw in Bash, the command-line shell at the heart of nearly every Linux, Unix, and macOS system. Bash had a quirk: it could pass functions to child processes through environment variables, and it would keep executing any commands that trailed the function definition. Since web servers, mail servers, and network devices routinely put attacker-controllable data into environment variables before calling Bash, an attacker could smuggle commands into something as ordinary as an HTTP header and have the server run them, with no authentication. It was trivially exploitable, and Bash was everywhere, so within hours of disclosure botnets were mass-scanning the internet. Coming six months after Heartbleed, it cemented 2014 as the year the internet learned how much of its foundation was decades-old code nobody had re-examined.

How it worked

Bash has a feature for passing a function to a child process through an environment variable. The flaw was that when Bash imported such a variable, it did not stop at the end of the function definition; it kept parsing and executing anything that came after it. So a variable set to () { :; }; <command> would, the moment Bash started up and imported it, run <command>. The canonical proof of concept was a single line, env x='() { :;}; echo vulnerable' bash -c "echo test", which prints vulnerable on an affected shell.

The danger was in how much software hands attacker input to Bash through environment variables without thinking about it. The classic case was Apache CGI: a web server copies incoming HTTP headers (like the User-Agent) into environment variables and then invokes a Bash script. So an attacker sending a header like User-Agent: () { :;}; <command> got the server to run their command, unauthenticated remote code execution from a single header. The same pattern existed in DHCP clients (a malicious DHCP server could run code on a connecting client through dhclient), mail filters, and OpenSSH's forced-command feature, where it could break out of a key restricted to a single command. No login, no interaction.

The damage

Bash is on virtually every Unix-like system on earth, plus countless embedded devices, routers, and appliances, many of which are never updated. Within hours of disclosure, botnets were mass-scanning and exploiting unpatched systems for DDoS and backdoors (within a week CloudFlare was tracking around 1.5 million attacks and probes a day). The first patch turned out to be incomplete, and a string of distinct follow-on CVEs followed as researchers found new parser flaws (CVE-2014-7169, then the memory-corruption bugs CVE-2014-7186 and 7187, and further function-parser issues), six in all. Rated the maximum CVSS 10.0 under the v2 scale used at the time (9.8 under the later v3) and trivially exploitable, it was one of the most severe vulnerabilities of its era, and because so much embedded gear shipped Bash and never received updates, vulnerable devices lingered for years.

Why Shellshock still matters

Shellshock is the legacy-code lesson in its purest form: a bug that sat unnoticed in foundational software for a quarter of a century, and became one of the most dangerous flaws on the internet the moment someone looked at it through a modern threat model. Bash predates the web; nobody had re-audited its environment-variable handling against the idea of internet-facing CGI scripts feeding it hostile input. The takeaways still apply: do not pass untrusted input into a shell or its environment; use APIs that run programs with explicit arguments instead of shelling out; reduce internet-facing attack surface; and patch or retire embedded devices that bundle old, foundational software. It is a sibling of Heartbleed: both proved that much of the internet runs on decades-old code maintained, and re-examined, by very few.

Comment le corriger

  • Patch Bash to a fixed version, and apply the follow-on fixes since the first patch was incomplete, on every system, including embedded devices and appliances that bundle it.
  • Audit for internet-facing services that pass untrusted input into environment variables before invoking Bash (CGI, DHCP, mail filters), and disable or rewrite the risky ones.
  • Hunt logs for exploitation strings (function-definition prefixes like `() {` in headers) and treat hits as a potential compromise.

Comment l’éviter

  • Do not pass attacker-controlled input into a shell or its environment; use APIs that invoke programs directly with explicit arguments instead of shelling out.
  • Reduce internet-facing attack surface: retire CGI and other patterns that hand untrusted input to a shell.
  • Keep an inventory of where foundational software like Bash runs, especially in embedded and unpatched devices, and retire what can no longer be updated.
  • Re-audit old, trusted software against a modern internet threat model; this bug was 25 years old and only dangerous once exposed to hostile input.

Références

Vulnérabilités liées

Tout Infra →