Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)

Updated -

Red Hat has been made aware of a vulnerability affecting all versions of the bash package as shipped with Red Hat products. This vulnerability CVE-2014-6271 could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Update: 2014-09-30 18:00 UTC

Two new flaws have been reported that are mitigated by the currently available Bash packages. Please refer to the FAQ for further information.

Update: 2014-09-29 05:00 UTC

Malware is circulating that exploits this vulnerability. For more details, see this article.

Update: 2014-09-26 05:15 UTC

Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169.

Updated bash packages that address CVE-2014-7169 are now available for Red Hat Enterprise Linux 4, 5, 6, and 7, Red Hat Enterprise Linux 5.6 Long Life, Red Hat Enterprise Linux 5.9 Extended Update Support, Red Hat Enterprise Linux 6.2 Advanced Update Support, and Red Hat Enterprise Linux 6.4 Extended Update Support, and Shift_JIS for Red Hat Enterprise Linux 5 and 6. See also Resolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169) in Red Hat Enterprise Linux.

Diagnostic Steps

Red Hat Access Labs has provided a script to help confirm if a system is patched against to the Shellshock vulnerability. You can also manually test your version of Bash by running the following command:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

If the output of the above command contains a line containing only the word vulnerable you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function.

Note that different Bash versions will also print different warnings while executing the above command. The Bash versions without any fix produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

The versions with only the original CVE-2014-6271 fix applied produce the following output:

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

The versions with additional fixes from RHSA-2014:1306, RHSA-2014:1311 and RHSA-2014:1312 produce the following output:

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

The difference in the output is caused by additional function processing changes explained in the "How does this impact systems" section below.

The fix for CVE-2014-7169 ensures that the system is protected from the file creation issue. To test if your version of Bash is vulnerable to CVE-2014-7169, run the following command:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

If your system is vulnerable, the time and date information will be output on the screen and a file called /tmp/echo will be created.

If your system is not vulnerable, you will see output similar to:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory

If your system is vulnerable, you can fix these issues by updating to the most recent version of the Bash package by running the following command:

# yum update bash

How does this impact systems

This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such.

All versions prior to those listed as updates for this issue are vulnerable to some degree.

See the appropriate remediation article for specifics.

The patch for CVE-2014-7169 introduces changes to how Bash evaluates environment variables. Applications which directly create Bash functions as environment variables need to be made aware of these changes. Previously, a function had to be stored in an environment variable of the same name. For example, the function "compute" would be stored in an environment variable named "compute". With the patch for CVE-2014-7169 applied, it would need to use the name "BASH_FUNC_compute()". As a result, there are now two pairs of parentheses in the environment string, as in "BASH_FUNC_compute()=() { }".

Functions written in Bash itself do not need to be changed, even if they are exported with "export -f". Bash will transparently apply the appropriate naming when exporting, and reverse the process when importing function definitions.

Services that create such environment variables will need to be restarted to work with the new version of Bash. This behavior is not used by any of the packages provided in any version of Red Hat Enterprise Linux.

Products Affected:

Product/Channel Fixed in package Remediation details
Red Hat Enterprise Linux 7 bash-4.2.45-5.el7_0.4 Red Hat Enterprise Linux
Red Hat Enterprise Linux 6 bash-4.1.2-15.el6_5.2 Red Hat Enterprise Linux
bash-4.1.2-15.el6_5.1.sjis.2 Red Hat Enterprise Linux
bash-4.1.2-9.el6_2.2 Red Hat Enterprise Linux 6.2 AUS
bash-4.1.2-15.el6_4.2 Red Hat Enterprise Linux 6.4 EUS
Red Hat Enterprise Linux 5 bash-3.2-33.el5_11.4 Red Hat Enterprise Linux
bash-3.2-33.el5_11.1.sjis.2 Red Hat Enterprise Linux
bash-3.2-24.el5_6.2 Red Hat Enterprise Linux 5.6 LL
bash-3.2-32.el5_9.3 Red Hat Enterprise Linux 5.9 EUS
Red Hat Enterprise Linux 4 bash-3.0-27.el4.4 Red Hat Enterprise Linux 4

Common Configuration Examples:

Red Hat performed an analysis to better understand the magnitude of this issue and how it affects various configurations. The below list is not exhaustive, but is meant to give some examples of how this issue affects certain configurations, and why the high level of complexity makes it impossible to specify something is not affected by this issue. The best course of action is to upgrade Bash to a fixed version.

Package Description
httpd CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
Secure Shell (SSH) It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
dhclient The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
CUPS It is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudo Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
Firefox We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
Postfix The Postfix server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

A more detailed analysis of the flaw is available at: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack

Frequently Asked Questions

This FAQ is for the vulnerability CVE-2014-6271 in Bash.

Some additional information regarding CVE-2014-6271 and CVE-2014-7169 is available at: https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/

Some additional information regarding customers who have RHEL 4 Standard or Premium Entitlements, but not ELS, is available at https://access.redhat.com/discussions/1211573

Why are there six CVE assignments?


The original flaw in Bash was assigned CVE-2014-6271. Shortly after this issue went public, a researcher found a similar flaw that was not blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. Recently, two more flaws were reported, although the details of these flaws are currently non-public, and they were assigned CVE-2014-6277 and CVE-2014-6278. The first four flaws have been fixed in the latest Bash packages currently available, and the last two flaws are mitigated by the same. As of this writing (2014-09-30) there are currently no known security flaws that these Bash packages are vulnerable to. Please refer to the actual CVE pages noted for the latest statements on these flaws.

I believe my system may have been compromised due to this vulnerability, what should I do?

If you have run the diagnostic steps in this article, and your system still appears to be vulnerable, or you believe your system has been compromised, open a support case with Red Hat or contact Red Hat support by phone.

Do I need to reboot or restart services after installing the update for CVE-2014-6271 and CVE-2014-7169?

If your system uses exported Bash functions, restarting affected services is recommended. Affected interactive users may have to re-login, and screen or tmux sessions may need to be restarted.

The Bash update provided to fix these issues changes the names of exported functions in the environment. If a function is exported by the old version of Bash, it is not recognized by newly started Bash processes after the update, and essentially becomes undefined. Restarting the services ensures that the new version of Bash exports functions under the expected name, making it visible again.

To find out which services need to be restarted (or which users have to re-login), execute the following command after updating:

$ grep -l -z '[^)]=() {' /proc/[1-9]*/environ | cut -d/ -f3

The returned PIDs belong to processes which are using the old exported function definitions in their environment. These processes must be restarted. To discover which service started a certain PID and needs restarting, on Red Hat Enterprise Linux 7, use the following command:

$ systemctl status <PID>

On Red Hat Enterprise Linux 6 and earlier, use the pstree -p or ps -axuf command and look for a particular PID.

Are other shells vulnerable to this issue?

Red Hat has tested other shells for this issue. We could not reproduce the behavior seen in Bash. If similar issues are discovered in other shells we will release updates as appropriate.

Are there any possible mitigations against this issue?

Please see Mitigating the shellshock vulnerability (CVE-2014-6271 and CVE-2014-7169) for details on potential mitigations if you are unable to install the updated packages. The best mitigation is to install the latest available packages (noted above) as they currently protect against all reported vulnerabilities.

Statement on Red Hat Website Vulnerability

The following Red Hat websites, which provide services to customers have been confirmed to be updated:

  • www.redhat.com
  • access.redhat.com (Red Hat Customer Portal)
  • rhn.redhat.com (Red Hat Network)

Red Hat utilises Salesforce to deliver services to customers. Salesforce have released a statement that it has determined Salesforce services are not vulnerable to this issue.

Red Hat has observed unsuccessful attempts to exploit this vulnerability against the above websites. We continue to monitor our systems to ensure their confidentiality, integrity and availability.

71 Comments

If you have support, please open a support case and we will help to address your specific questions. Thank you.

Mark, you have posted the similar to oss-security:

http://seclists.org/oss-sec/2014/q3/741

Responses as this:

http://seclists.org/oss-sec/2014/q3/746

or several other posts sent out before your mail explain the difference between the functionality you point out (definition of functions using a variables with names from a specific name space) and the original issue (the problem that can be triggered with any environment variable name and hence exploitable via multiple remote vectors).

This may not be the best place to duplicate the discussion.

More relevant / real-world response would be this one:

http://seclists.org/oss-sec/2014/q3/762

Please don't try to make anyone boil the oceans.

It was similar but not identical. I did point out that Florian's prefix/suffix patch was not going to protect against the setuid/setgid exploit that we are facing, and that was an important point to make.

Anyway, I see my original comment has been hidden or deleted from this thread, which now makes some of the answers below difficult to understand, as the context has been removed.

I have, however, continued the discussion here if readers would like the full context:

http://seclists.org/oss-sec/2014/q3/859

That said, I would urge people to install Florian's patch ASAP, as it is the best protection we have so far. But I suspect more patches will follow ...

Florian's prefix/suffix patch did not aim to add protection for (unsafe) setuid/setgid applications that allow caller to set arbitrary environment variables for processes they spawn.

Your original comment has not been hidden or removed, but I see it's not displayed when following URLs from email notifications. Use one of the following URLs to view it:

https://access.redhat.com/articles/1200223#comment-824053
https://access.redhat.com/comment/824053#comment-824053

Hi

I noticed that after installed the new bash-3.2-33.el5_11.4, the release number reported by bash itself does not match 3.2-33:

# rpm -qa bash
bash-3.2-33.el5_11.4

# bash --version
GNU bash, version 3.2.25(1)-release (i386-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

i have the same issue .... any updates about that ?

Hello,

This is an expected behaviour due to Red Hat's backport policy. Please check https://access.redhat.com/security/updates/backporting for more information.

Would like to point out that this was mentioned here yesterday: http://www.clevcode.org/cve-2014-6271-shellshock/ - "pwn me twice".

It's nowhere near as high-impact as the original issue, but if you do have local privileged executables that spawn subprocesses ... there's still a significant problem.

How can we update bash rpm through RHN for all the servers at once ?

[root@qa-web01 ~]# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
Does this display is accepted after applying patch.

We have modified the diagnostic steps. Please use the updated one

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

The latest rpm from this morning, broke at jobs on RHEL 6, with environment-modules rpm installed.

sh: line 32: syntax error near unexpected token =\(\)\ {\ \ eval\ \/usr/bin/modulecmd\ bash\ \$*`"
"}'
sh: line 32: `"}; export BASH_FUNC_module()'

You can fix the issue by commenting out the following lines.

head -3 /usr/share/Modules/init/bash

module()()()() { eval /usr/bin/modulecmd bash $*; }

export -f module

hi please provide the download path forthe package bash-3.0-27.el4.2.i386... we dont findthis in redhat ..

Please open a ticket for help you with you issue.

Sanjay Pal, that package is only available in the RH4 ELS stream, if you did not purchase the support you can not get the package.

we are little confused on this !!!!
http://www.csoonline.com/article/2687958/application-security/shellshock-bash-vulnerability-being-exploited-in-the-wild-red-hat-says-patch-incomplete.html ..

rpm -q bash

bash-4.1.2-15.el6_5.1.x86_64

env ls='() { echo vulnerable; }' bash -c ls

vulnerable

Christna Plummer, you want to run the "yum update bash" again, today, update to this package version: bash-4.1.2-15.el6_5.2
(This is for RHEL 6)
If necessary, if "yum update bash" does not update, do this first:
yum clean all
yum -y update bash

Is this normal?

[root@node2 opt]# rpm -Uvh bash-3.0-27.el4.4.x86_64.rpm
璀﹀憡锛歜ash-3.0-27.el4.4.x86_64.rpm: V3 DSA 绨界珷锛歂OKEY, key ID db42a60e
婧栧倷涓.. ########################################### [100%]
1:bash ########################################### [100%]
[root@node2 opt]# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

Yes it is. We have updated the instructions. Please refer the diagnostic steps for more information

where i can download the new version of bash, we run RHEL6.2.

Hello,

You can download it from our customer portal. If you need assistance, please contact Red Hat Technical Support

Hi,

Can you provide us with a link to the batch to download it and update the bash manually?

Please review the article https://access.redhat.com/node/1207723. If it does not answer your questions, then please contact Red Hat Technical Support. We should be able to assist you further

We understand what linux reboot is not require, but: do We need to restart database, apache, or third-party products?

I have bash-4.1.2-15.el6_4.x86_64
can someone tell me what Updated bash packages that fixed and where to get it.
thanks

You can download the package bash-4.1.2-15.el6_5.2 from the customer portal

1 - https://access.redhat.com/downloads/
2 - select Red Hat Enterprise Linux
3- Choose the version as 6.5
4- hit packages tab and enter bash in the filter section
5- Choose bash listed under server rpms
6- Download the package

We understand what linux reboot is not requiere, but do We need to restart database, apache or third-party products ?

A restart of application is also not required.

Is there fix for RHEL 5 32 bit OS?

Yes you can download the 32 bit version from bash-3.2-33.el5_11.4

1 - https://access.redhat.com/downloads/
2 - select Red Hat Enterprise Linux
3- Choose the version as 5.11 and arch as i386
4- hit packages tab and enter bash in the filter section
5- Choose bash listed under server rpms
6- Download the package

Hi,

Can you let us know the location to download the package bash-3.0-27.el4.4. yum utility is not for RHEL 4 environment.

For accessing the RHEL4 security errata, you need to have Red Hat Enterprise Linux Extended Life Cycle Support subscription. If the systems is registered and subscribed to the ELS channel, then you can apply the package using the command "up2date bash". If you do not have ELS, then please contact Red Hat Technical Support for further assistance

This RPM

bash-3.2-33.el5.1.x86_64.rpm

provided partial mitigation:

labscvdev0156:root ~ # ./shellshock-test.sh
This system is safe from CVE-2014-6271 https://access.redhat.com/security/cve/CVE-2014-6271
This system is vulnerable to CVE-2014-7169 https://access.redhat.com/security/cve/CVE-2014-7169
Please run 'yum update bash'. If you are using satellite or custom repos you need to update the channel with the latest bash version first before running 'yum update bash'. Please refer to 'https://access.redhat.com/articles/1200223' for more information

yum update bash is futile. My system sees RHN through Spacewalk.

-drl

For RHEL5, you should apply bash-3.2-33.el5_11.4 to resolve CVE-2014-7169 as well.

Is the Linux 6.3 kernels fixed yet. I have several 6.3 and yum update bash fails to find any packages. But all my 6.4 md 6.5 have been fixed with the update.

If the systems are registered properly, then "yum update bash" should work. If you need assistance, contact Red Hat Technical Support

i have redhat 4 update 9 , i can not any bash version for that OS version can some one help ?

Sherif,

This thread should answer your question regarding RHEL 4.
https://access.redhat.com/discussions/1211573

Hi, Guru

Our bash script run as a daemon on the background, does the daemon running normal during bash upgrading? Do we need restart the daemon after the bash updated?

Thanks!

Answer mentioned for the question "Do I need to reboot or restart services after installing this update?" included in the "Frequently asked question" section should be applicable here as well

Dear All,

We are currently running RHEL 5.4 (64 bit) with "bash-3.2-32.el5_9.1". However, in the resolution doc# 1207723 following is mentioned.

In order to avoid exploitation from CVE-2014-6271, ensure that your system is updated to at least the following versions of Bash.
RHSA-2014:1293
Red Hat Enterprise Linux 5 - bash-3.2-33.el5.1

And, In order to avoid exploitation from CVE-2014-7169, ensure that your system is updated to at least the following versions of Bash, which also includes the prior fixes.

RHSA-2014:1306
Red Hat Enterprise Linux 5 - bash-3.2-33.el5_11.4

This means in order to fix the above two bugs, we need to apply both of these RPM's ??

Because, if we upgrade to "bash-3.2-33.el5.1" only "CVE-2014-6271" shall be fixed and if we upgrade to "bash-3.2-33.el5_11.4" only "CVE-2014-7169" shall be fixed.

Please throw some light on this ASAP.

regards
MARQ

Marq,

Applying bash-3.2-33.el5_11.4.x86_64.rpm will cover both vulnerabilities as updates and fixes are cumulative, so the current version of the package includes fixes for previous issues.

To determine which is the most current and up to date version of the bash package for your OS you can browse the download section of the customer portal, eg.
https://access.redhat.com/downloads/content/rhel---5/x86_64/867/bash/3.2-33.el5_11.4/x86_64/37017186/package

Got it...Thank You so much. Appreciate your quick reply.

I hope I can help here with some of you having trouble with bash updates. What I have found is that anything (ES6) on kernel-2.6.32-358.xx will get:
No Packages marked for Update

...even though bash has not been updated as of yet. Both older and newer kernel versions have been working fine for me. I'm going to try to update the handful of servers I have at that version and see if the issue is resolved!

running RHEL6.2 and have installed bash-4.1.2_15.el6_5.1.x86_64 via rpm -Uvh. rpm -qi bash reports the update version.

if we run the 7169 test string we get that it’s still vulnerable. However, I’m not sure if it’s a syntax issue or not. In the env statement, is that a space between () and { ? With a space the results are that our system is vulnerable. Without the space, our system is not vulnerable. Can someone verify the correct syntax?

Bert Fukuda,

You need bash-4.1.2_15.el6_5.2 for RHEL 6 to "pass" the 7169 test string.

Doug - Figured out I had the wrong version. Thanks!

Hi, is there bug fix for release 3?

I am having the following release.
Red Hat Enterprise Linux ES release 3 (Taroon Update 6)

RHEL 3 has reached End of Life. So there will be no bug fixes

Leslie,

Contact Red Hat Technical Support. Red Hat is reviewing the option of delivering a one time fix for RHEL3 even though RHEL3 has reached EOL

Hi,
Is there fix for release Red Hat Enterprise Linux 5.7 , My Satellite Server is not showing any errata for that .

Hi,

Is there a fix for Red Hat Enterprise Linux Server release 5.7 (Tikanga)? Still have a vulnerable machine and no packages are available from yum update.

Also, running "rpm -q bash" shows that I could get bash-3.2-32.el5 but running a bash version check shows "GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)". Back port maybe?

Yes, 'backport' exactly. It is well explained here:

https://access.redhat.com/solutions/1216893

Thanks for the response Akemi.

It would still be nice to know if there already is a fix for RHEL 5.7. Could I actually download bash-3.2-33.el5_11.4.x86_64.rpm and update it manually (Upgrade rpm file)? Right now the installed package is bash-3.2-32.el5.

@Carlo Encinareal,
Yes, you can installed bash-3.2-33.el5_11.4 on RHEL 5.x

Thanks Matthew.

Hello ,
bash available at my server is bash-4.1.2-15.el6_5.2.x86_64 , Am I protected from bash Vulnerability , My OS details are

2.6.32-431.17.1.el6.x86_64 #1 SMP Fri Apr 11 17:27:00 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux Server release 6.5 (Santiago)

Yes the system is protected from all known/reported CVE's

On 5th/Oct, the upstream released yet another fix.
http://lists.gnu.org/archive/html/bug-bash/2014-10/msg00045.html
Is this affected on latest bash on RHEL4 to 7 systems?

A combination of nested command substitutions and function
importing from the environment can cause bash to execute
code appearing in the environment variable value following
the function definition.

is there a patch available for bash-2.05b-41.7 (Red Hat Enterprise Linux AS release 3)

What about CVE-2014-6277 ?

Red Hat Bugzilla – Bug 1147189 seems not to be fixed....

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)
$ bash -c "f() { x() { _;}; x() { _;} <<a; }" 2>/dev/null || echo vulnerable
Segmentation fault (core dumped)
vulnerable

If the command outputs "vulnerable", you still have the local parser bug. But it does NOT make you vulnerable to remote exploit attacks.

The only RELIABLE test of whether you are vulnerable to Shellshock is:

env 'bad=() { echo vulnerable; }' bash -c bad

If that prints:
bad: command not found

then your bash is secure, even if it still has parser bugs. If it prints vulnerable, then your bash is broken, even if it "passes" the parser bug test above by not dumping core.

I have the current bash rpm package on my RHEL 4 64 bit system and it still says "vulnerable"

[root@wexsvrp1 log]# env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token )'
bash: BASH_FUNC_x(): line 0:
BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test
[root@wexsvrp1 log]# rpm -qa bash
bash-3.0-27.el4

bash-3.0-27.el4 is not the fixed version, bash-3.0-27.el4.4 is (note the trailing extra .4).

where can I download the fixed version?

how i can downgrade the BASH in to previous state?

current is bash-3.2-33.el5.1, i would like to rollback it to 3.2-32.el5.

yum downgrade bash-3.2-32.el5

Hello ,

We installed the bash-3.2-33.el5_11.4.i386.rpm on 5.2 32 bit and executed the $ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

But we still get the error below

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

Can you please advise .
Regards

After updating the patch, you would get these messages. It is no longer vulnerable. The cause of these messages are already documented in the article. Feel free to contact Red Hat Technical Support if the information in the article does not answer your question

Hello thanks for your answer,

Just one question; if I executed the command below in this case , should I get a test or a vulnerable message

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

Thanks for your answer

Pages