Bash "shellshock" CVE-2014-6271 CVE-2014-7169 - rated 10 !

That looks like the patched version (3.2-33.el5.1)

https://rhn.redhat.com/errata/RHSA-2014-1293.html

Once installed you can read about the patch with:

rpm -q --changelog bash | head

Alright then I'm pretty sure mine are fine, the shell scripts are run using exec in mod_php, no cgi is involved, so as far as I understand it an attacker has no way of passing an environment variable through to the shell.

Correct:

PHP scripts executed with mod_php are not affected even if they spawn subshells.

https://securityblog.redhat.com/2014...ection-attack/

I've posted a note to the Linux - News forum (and a couple other places). A sticky in Linux - Security may be in order, but I'm not sure a site wide notice is needed at this time.

--jeremy

What I don't get is why the the bash developers EVER thought it would be a remotely good/safe idea to pull in function declarations from environment variables in the first place.

Even after this bug is fixed (which apparently it isn't yet), this is still a vulnerability in bash IMO.

Take the following code, running on a patched system, setting an environment variable to replace a standard Linux command with custom code:

$ env ls='() { echo this is a fake ls; }' bash -c "ls"
this is a fake ls

If an attacker puts that "ls" function declaration in an environment variable through cgi, they've effectively just replaced the "ls" command with their own code. They could replace ls, cd, read, even echo with custom code.

$ ls
$ env echo='() { touch file; }' bash -c "echo 5"
$ ls
file

Shellshock is a problem, bash should not execute commands after the function declaration, but why is this even a feature in the first place??? Even after shellshock is fixed, this "feature" just seems like a major security problem to me.


edit: apparently cgi prefixes any environment variables before setting them for the shell, so it's not as bad as I had feared. I still don't like the notion of cgi setting http headers as environment variables, and then bash turning environment variables into functions though.

my centOS 6 repos dont even show the fix as available, what gives?

can we wrap bash to mitigate the issue ?

Originally Posted by tux100 rpm -qa |grep bash says RHEL 5.8 bash-3.2-32.el5 yum update bash will upgrade bash to 3.2-33. << Pretty sure this is not a patched bash. ================================================================================== Package Arch Version Repository Size ================================================================================== Updating: bash x86_64 3.2-33.el5.1 rhel-x86_64-server-5 1.8 M

see https://access.redhat.com/articles/1200223

i am wondering why the repos dont have the fixed package yet.

Originally Posted by suicidaleggroll What I don't get is why the the bash developers EVER thought it would be a remotely good/safe idea to pull in function declarations from environment variables in the first place. Even after this bug is fixed (which apparently it isn't yet), this is still a vulnerability in bash IMO. Take the following code, running on a patched system, setting an environment variable to replace a standard Linux command with custom code: $ env ls='() { echo this is a fake ls; }' bash -c "ls" this is a fake ls

what bash package exactly was installed as the "fix"?

Originally Posted by Linux_Kidd what bash package exactly was installed as the "fix"?

I'm not sure what you're asking. Bash doesn't have packages, bash is the package. The initial fix for shellshock is right here:
http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-025

It's not complete, but it takes care of the primary vulnerability. Even once bash is fixed completely, attackers will still be able to define custom functions in any resulting bash shell by manipulating the environment though, which makes me uneasy.

Originally Posted by suicidaleggroll I'm not sure what you're asking. Bash doesn't have packages, bash is the package. The initial fix for shellshock is right here: http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-025 It's not complete, but it takes care of the primary vulnerability. Even once bash is fixed completely, attackers will still be able to define custom functions in any resulting bash shell by manipulating the environment though, which makes me uneasy.

what bash package exactly? the CentOS repo shows an available bash package, but one that is listed as vulnerable by RedHat.

the link shows c files from 12Sep and 14Sep, looks like it wasnt fixed yet at that time, or am i missing something? thus we are still waiting on a fix to handle the complete issue?

CentOS back-ports security updates. So even though the bash version is "vulnerable" according to the reports, the shellshock fix has been back-ported to take care of the problem.

If you run

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

before and after running the yum update, you'll see that it takes care of the problem.

This vulnerability still hasn't been fixed though:

env X='() { (a)=>\' bash -c "echo date"; cat echo

oddly, bash-4.1.2-15.el6_5.1.i686 is listed in my CentOS repo but not as a security fix !! yum check-update --security , no packages available.
but bash-4.1.2-15.el6_5.1.i686 is listed on RH site as vulnerable, so i guess the fix was bad and we are still waiting ??

4.1.2-15.el6_5.1 does have the fix for vulnerability #1, that's the version installed on my CentOS 6.5 systems:

$ 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

Originally Posted by suicidaleggroll 4.1.2-15.el6_5.1 does have the fix for vulnerability #1, that's the version installed on my CentOS 6.5 systems: $ 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

even after this ver of bash, still same issue, arbitrary code execution, no?

Originally Posted by suicidaleggroll CentOS back-ports security updates. So even though the bash version is "vulnerable" according to the reports, the shellshock fix has been back-ported to take care of the problem. If you run env x='() { :;}; echo vulnerable' bash -c "echo this is a test" before and after running the yum update, you'll see that it takes care of the problem. This vulnerability still hasn't been fixed though: env X='() { (a)=>\' sh -c "echo date"; cat echo

i run the 1st one after yum update bash, my bash is now bash-4.1.2-15.el6_5.1.i686, still same issue, i get "this is a test" returned to me.

the 2nd command, i get X syntax error, error importing function, etc

perhaps you have the two backwards ??
verified with rpm -qf /bin/bash