SoylentNews is people
SoylentNews
Ars reports that a new bug has been found in GNU Bash allows remote attackers to execute arbitrary code by setting the process trailing strings after function definitions in the values of environment variables.
This bug is reported to be present in RHEL (ver 4 through 7), Fedora, CentOS (ver 5 through 7), Ubuntu (ver 10.04 LTS, 12.04 LTS, and 14.04 LTS), Debian, and even OS X Mavericks.
This bug is exploitable through Apache servers with mod_cgi and mod_cgid loaded, OpenSSH, malicious DHCP servers in a compromised wireless access point through dhclient, as well as the CUPS printing system.
The Ars also includes a simple single liner that will test your setup for the newly found discovery:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
A vulnerable system will output the following:
vulnerable
this is a test
While a patched or unaffected system outputs:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
A patch is already out, so administrators are advised to update Bash.
Editor's Update: Security Engineer Tavis Ormandy has said "The bash patch seems incomplete to me, function parsing is still brittle".
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @07:29AM
The summary seems to be describing a bug, not a vulnerability. Bash doesn't open any listening ports, you cannot connect to bash. If you have access to run bash, you already have full access under that userid, and bash is not setuid. If it was, that would be the hole. And any modern *nix ignores the setuid bit for scripts, so that can't be it either.
Ok, 15 years ago, we did write some cgi-scripts in bash or other shell script, but even back then, we knew that making a shell script accessible on the net was a security problem. It was never supposed to do that.
So, how does this bug make it possible to do anything that the user doesn't already have permissions to do?
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @09:04AM
escaping limited shell in ssh, root access, etc (but each case seems to be possible with some specific configuration, for instance escaping ssh is possible only if you enables AccessEnv which is disabled by default)
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ [redhat.com]
(Score: 3, Informative) by choose another one on Thursday September 25 2014, @09:32AM
It is a vulnerability because environment variables cross process/user permission boundaries, and therefore the contents should be treated as untrusted. Bash, it appears, executes them as code, and moreover the environment variable can have any name. Environment variables should never be trusted precisely because they cross boundaries - think setuid. Whatever process sets the environment variable cannot possibly check for all possible malicious content for all possible programs that could be launched down the line with that environment - it is down to each process _reading_ an environment variable to do so with suitable care, and blindly executing it to define a function is not.
Certain standard services, such as cgi, put information from remote untrusted clients/servers into the environment. The cgi script itself obviously does not have to be a bash script - if it is launched through the shell or ever launches any other command via the shell (popen, system() etc.) then boom.
Other attack surfaces include ssh (think TERM), now think "locked down" ssh access for e.g. Git. Not so "locked down" now.
Now think about your DHCP client. How do you setup the interface configuration it does, some kind of script maybe ? What user might that script be running as, considering what it needs to do ? How does the client process pass the info it gets from the DHCP server into the script ? Ever connected to a public wi-fi ? Boom.
Make no mistake, this is big, possibly bigger than heartbleed, and people have likely only just scratched the surface of possible attack vectors. The NSA have probably had this one in the bank for years.
(Score: 0) by Anonymous Coward on Thursday September 25 2014, @01:58PM
On the other hand, for scripts you would use /bin/sh which at least on Debian systems is not bash. Also system() uses /bin/sh. So any Debian system using properly written scripts should be fine (unless dash is also vulnerable).
(Score: 2) by choose another one on Thursday September 25 2014, @03:14PM
Yep, /bin/sh != bash would be a start.
Not sure how much that will break on other systems. Might be better to ban bash from non-interactive use, or get rid of it entirely, the whole idea of parsing environment variables as code is an exploit waiting to happen - putting band-aids on the parser will be a temporary and fragile fix (as already shown).