GNU Bash serious security CVE

[HulaHoop]

A new horrific bash security bug has been reported a few hours ago. On the vulnerability scale its the equivalent of thermonuclear fallout.

In the context of Whonix, CPFP is affected. Things like this make me question whether it makes sense to provide CPFP by default.

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

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:
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

[Patrick]

I knew this would come up.

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.]

[HulaHoop]

Update: Some more bugs forund and being fixed, some minor compared to the original are now coming up. There is major auditing going on more CVEs expected.

https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/

[Patrick]

Will be fixed in 9.2:
https://www.whonix.org/blog/whonix-9-2-testers-wanted

[whonick]

So glad I run Qubes as my host and isolate everything.

[HulaHoop]

The newest episode in the shellshock saga http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html a second remotely exploitable bug with the same gravity as the first (of many).

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.

[HulaHoop]

New articles published, important particularly if you run webservices.

https://access.redhat.com/articles/1200223 (List of affected client-side software that makes use of bash environments,besides whether or not you are doing so intentionally)

https://access.redhat.com/articles/1212303 (mitigation techniques, but its recommended you patch immediately)