GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.
A detailed explanation of the bug with non-cryptic language:
I am still trying to grasp the exploit, but don’t see how this could be exploited. As I understand it at the moment, for remote exploitation, a variable has to be set using output from untrusted networks and then get exported. I am not aware that any of Whonix’s script do such things.
Finding this bug is a good thing. Bash is now getting more attention and people are looking around if they find similar bugs.
[Anyhow, it will be fixed in Whonix 9.1, which I am currently uploading.]
Well... so, to get to the point: I've been fuzzing the underlying function parser on the side - and yesterday, bumped into a new parsing issue (CVE-2014-6277) that is almost certainly remotely exploitable and made easier to leverage due to the fact that bash is seldom compiled with ASLR. I'll share the technical details later on; for now, I sent the info to the maintainer of bash and to several key Linux distros. In general terms, it's an attempt to access uninitialized memory leading to reads from, and then subsequent writes to, a pointer that is fully within attacker's control. Here's a pretty telling crash:
Soon after posting this, I also bumped in the sixth and most severe issue so far, essentially permitting very simple and straightforward remote code execution on the systems that are patched against the first bug. It’s essentially a “put your commands here” type of a bug similar to the original report. I will post additional details on Tuesday to give people enough time to upgrade.
Until now, the official patches close the bugs found rather than fix up the parsing mechanism of this part in bash. Work on cleaning up that code is still ongoing.