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.
Norihiro Tanaka, a Japanese open-source developer, noted the problem in an e-mail to the bug-bash list today. By using an environmental variable called cat—the same name as a Unix utility that can concatenate files—he was able to bypass the fixes in the latest bash patch and pass through executable commands.
Wheeler noted this vulnerability as well, in an email to both oss-sec and the bug bash list:
I appreciate the effort made in patch bash43-026, but this patch doesn't even BEGIN to solve the underlying shellshock problem. This patch just continues the "whack-a-mole" job of fixing parsing errors that began with the first patch. Bash's parser is certain have many many many other vulnerabilities; it was never designed to be security-relevant…John Haxby recently posted that "A friend of mine said this could be a vulnerability gift that keeps on giving.” Bash will be a continuous rich source of system vulnerabilities until it STOPS automatically parsing normal environment variables; all other shells just pass them through! I've turned off several websites I control because I have *no* confidence that the current official bash patches actually stop anyone, and I am deliberately *not* buying products online today for the same reason. I suspect others have done the same. I think it's important that bash change its semantics so that it "obviously has absolutely no problems of this kind".
In other words, “Shellshock” may be partially patched, but it’s still highly dangerous on systems that might use bash to pass information to the operating system or to launch other software. And it may take a significant change to fix the code.
Wheeler made two specific recommendations for fixes to bash that will essentially break backward compatibility with older bash versions. The first is an idea suggested by German computer security expert Florian Weimer to add a prefix to bash functions, preventing them from being named the same thing as system variables (one of the mechanisms used to exploit the current bug). The second recommendation, put forward originally by NetBSD developer Dr. Christos Zoulas, is to allow bash to only import environmental variables into bash when explicitly requested—eliminating the risk of any other bugs in bash’s command parsing from accidentally bringing in malicious code or irrelevant data lying around in random defined environmental variables. Both of these changes, Wheeler said, are already being made by developers—function importing has been disabled by default in FreeBSD’s bash implementation in the latest fix.
These fixes technically break backward compatibility for bash, but Wheeler and others believe that they won’t affect the vast majority of bash-dependent systems. However, they will require developers who’ve used bash—and there are many, many software systems that rely on bash in some way—to thoroughly test and possibly modify their own code.
All of this means that the Shellshock bug will likely require many older services to be simply shut off until patches are fully implemented and tested. And there are many devices in the field—embedded systems that run versions of the Linux operating system that don’t use a streamlined utility system such as BusyBox or some other shell—that will require attention as well.
reader comments
147