Still more vulnerabilities in bash? Shellshock becomes whack-a-mole

It's now bash-a-mole.

Remember when we said that a new patch had fixed the problems with the last patch to fix the rated-highly-dangerous “Shellshock” bug in the GNU Bourne Again Shell (bash)? You know, that bug that could allow an attacker to remotely execute code on a Linux or Unix system running some configurations of Apache, or perhaps the Git software version control system, DHCP network configuration or any number of other pieces of software that use bash to interact with the underlying operating system? Well, the new patch may not be a complete fix—and there may be vulnerabilities all the way down in the bash code.

Here's how the Shellshock vulnerability works, in a nutshell: an attacker sends a request to a Web server (or Git, a DHCP client, or anything else affected) that uses bash internally to interact with the operating system. This request includes data stored in an environmental variable. Environmental variables are like a clipboard for operating systems, storing information used to help it and software running on it know where to look for certain files or what configuration to start with. But in this case, the data is malformed so as to trick bash into treating it as a command, and that command is executed as part of what would normally be a benign set of script. This ability to trick bash is the shellshock bug. As a result, the attacker can run programs with the same level of access as the part of the system launching a bash shell. And in the case of a web server, that's practically the same level of access as an administrator, giving the attacker a way to gain full control of the targeted system.

David A. Wheeler, a computer scientist who is an acknowledged expert in developing secure open-source code, posted a message to the Open Source Software Security (oss-sec) list this evening urging more changes to the bash code. And other developers have found that the current patch still has vulnerabilities similar to the original one, where an attacker could store malicious data in a variable named the same thing as frequently run commands.

Read 6 remaining paragraphs | Comments