Major Bash Vulnerability Affects Linux, UNIX, Mac OS X

A critical remote code execution vulnerability in Bash, present in almost all Linux, UNIX and Mac OS X deployments, has been discovered. Experts advise immediate patching.

A critical vulnerability in the Bourne again shell, simply known as Bash and which is present in most Linux and UNIX distributions and Apple’s Mac OS X, has been discovered and administrators are being urged to patch immediately.

The flaw allows an attacker to remotely attach a malicious executable to a variable that is executed when Bash is invoked.

“It’s super simple and every version of Bash is vulnerable,” said Josh Bressers, manager of Red Hat product security. “It’s extremely serious, but you need very specific conditions in place where a remote user would be able to set that environment variable. Thankfully, it’s not common.”

For context, Bash is present everywhere on Linux and UNIX systems, and this bug will invite comparisons to the Heartbleed OpenSSL vulnerability. The Bash bug was discovered by Stephane Chazelas, a Unix and Linux network and telecom administrator.

Patches are starting to roll out from the major Linux distributions, Red Hat included, which acted immediately upon learning of Chazelas’ discovery once it was posted to the OSS security mailing list.

“Lots of stuff calls Bash and I would bet you there are things in most environments that call Bash and you don’t even know they’re doing it,” Red Hat’s Bressers said. “We did a ton of analysis on various things Red Hat ships that we decided were a high risk. It’s one of those situations where there are infinite variants you have to deal with. Heartbleed, for example, was easy to understand and all were affected the same way.”

“No two systems are affected the same way here. Upgrade Bash and don’t mess around,” Bressers said. “Even if you think you’re OK, you’re probably not.”

Bressers said the vulnerability allows an attacker to create environment variables that include malicious code before the system calls the Bash shell.

“These variables can contain code, which gets executed as soon as the shell is invoked,” Bressers wrote in a blogpost. “The name of these crafted variables does not matter, only their contents.”

Some of the more critical instances where the vulnerability may be exposed is on Apache servers for example, using mod_cgi or mod_cgid if either of those scripts is written in Bash. The vulnerability can also be used to bypass ForceCommand in sshd configs, Bressers wrote. ForceCommand is supposed to limit remote code execution, but exploiting this vulnerability sidesteps that protection. Some Git deployments over SSH would be affected here.

Red Hat includes links to a diagnostic step that would allow users to test for vulnerable versions of Bash.

The patch ensures that executable code is not allowed after the end of a bash function, Bressers said.

“It’s one package, and you don’t have restart your system or restart services,” Bressers said of the patch. “Once researchers start looking at this, there’s always the fear they will figure something new out. Hopefully not, otherwise we may have to start over.”

Suggested articles


  • ejr on

    This is not a vulnerability. This is a syntactical peculiarity of the bash scripting language. MAYBE it's a bug. THAT IS ALL. This itself isn't remotely exploitable unless an attacker already has remote access anyways. So what if an 'attacker' can run bash code in an unconventional place? If the 'attacker' already has access to a bash prompt, then you've got bigger problems. As a security professional, this whole "Shell Shock" thing is a big trolling joke. I'm not sure how this vulnerability alert REALLY started, but my hunch is that whoever did it secretly doesn't like bash, OS X, Linux, or Unix, and wants to slander those things through fear-mongering.
    • ajk on

      Wrong, apache will suck in http variables into bash such as "Host:” as REMOTE_HOST.
    • Chris on

      @Ejr: May not want to advertise yourself as a "security professional" if you don't understand the significant consequences of this vulnerability.... As others have already pointed out, Apache/CGI alone pose a massive massive security problem due to this vulnerability.
  • Bart on

    this will not be an issue for people that always install updates as soon as they are available which I always do. for those that don't pay attention or don't ever update they honestly get what they deserve.
  • rottenapple on

    "this thing is clearly wormable, and can easily worm past firewalls and infect lots of systems." "Someone is using masscan to deliver malware."
  • Freddy on

    @Ejr: I think bash is used on a lot of other systems in places you wouldn't expect: For example :: Cpanel uses CGI with bash script.
  • Knut on

    This is a utter rubbish made by people with little knowledge of the bash shell. It may be a threat had bash run on Windows, but shell substitution of strings is essential in Unix/linux/MacOS shel script. But to be a security issue, it must violate security - like be able to read a file you otherwise could not read. That is NOT THE CASE. All system security remains in place - Linux is NOT Windows, security is not monitored, it is distributed and enforced.
  • Michael Liben on

    To repeat a security adage, "there are two kinds of people; those who know they've been hacked and those who don't."

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.