Bash exploit

[flyingfsck]

A bad one:

https://bugzilla.redhat.com/show_bug...=CVE-2014-6271

Time for yum update bash?

[nonamedotc]

Fedora fixes in

Fedora 19 - http://koji.fedoraproject.org/koji/b...buildID=580602

Fedora 20 - http://koji.fedoraproject.org/koji/b...buildID=580601

Fedora 21 - http://koji.fedoraproject.org/koji/b...buildID=580600

[Dutchy]

Good information at one of the last links from that bz page.

Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

• ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
• Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
• PHP scripts executed with mod_php are not affected even if they spawn subshells.
• DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
• Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
• Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

For end-users it looks like a bad DHCP server is the only likely attack vector.
For servers the situation looks more dire.

[Conz]

Does anyone have something on how to fix this on older releases ?
I have a few machines that i have not been able to update for various reasons that range from fc15 to 18.

I've never manually compiled a new bash before and pretty sure things will be bad if it goes wrong.

[Dutchy]

Apparently the current fixes are incomplete but luckily there is a workaround (for vulnerable services).

[bobbyr]

Are there any plans to release a fix for Fedora versions that have already passed their EOL date? I have a machine running Fedora 16 that desperately needs a patch.

[sea]

@ bobbyr: Then despertly update to F21, should be due today (if i got that right).

[flyingfsck]

Or just delete bash and make link to sh?

[bobbyr]

@ bobbyr: Then despertly update to F21, should be due today (if i got that right).

I cannot upgrade (company version of Fedora,) and the security team hasn't posted any official documentation on how to upgrade D=

[bobbyr]

Or just delete bash and make link to sh?

sh is bash...

$ sh --version
GNU bash, version 4.2.37(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.[COLOR="Silver"]

[jonnycat]

Fedora fixes in

Fedora 19 - http://koji.fedoraproject.org/koji/b...buildID=580602

Fedora 20 - http://koji.fedoraproject.org/koji/b...buildID=580601

Fedora 21 - http://koji.fedoraproject.org/koji/b...buildID=580600

Any idea when these are going to make it into the repos?

[sea]

F20 just hit the updates:

bash x86_64 4.2.47-4.fc20 updates 997 k

@ bobbyr: The updates will NOT be available to F16... only F19, 20 and 21.

[JustMeHere2]

Looks like 4.2.47-4.fc20 also will have an update coming out real soon. From the bug: "Red Hat has become aware that the patches shipped for this issue are incomplete."

[notageek]

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

#shellshocked

yum info bash
Loaded plugins: fastestmirror, langpacks, refresh-packagekit
Determining fastest mirrors
 * fedora: ftp.cuhk.edu.hk
 * updates: ftp.cuhk.edu.hk
google-chrome                                                                                                                                     3/3
Installed Packages
Name        : bash
Arch        : x86_64
Version     : 4.2.47
Release     : 4.fc20
Size        : 3.5 M
Repo        : installed
From repo   : updates
Summary     : The GNU Bourne Again shell
URL         : http://www.gnu.org/software/bash
License     : GPLv3+
Description : The GNU Bourne Again shell (Bash) is a shell or command language
            : interpreter that is compatible with the Bourne shell (sh). Bash
            : incorporates useful features from the Korn shell (ksh) and the C shell
            : (csh). Most sh scripts can be run by bash without modification.

[flyingfsck]

"sh is bash..."

Damn, I suppose the merge happened 30 years ago already, but I can still remember them being different with subtleties that would break some scripts!