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.

86 Comments

When will bash-4.1.2-15.el6_4.1 be available?

It should be available now:

# yum update bash

4.1.2-15.el6_5.1

Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Sun Jul 27 15:55:46 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux I can't get an update what's up with that?

cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)

It should be available now:

# yum update bash

4.1.2-15.el6_5.1

I just tried yum update bash and it reports no packages marked for update.

to ensure that your yum is not using an old cache, you can use yum clean all and try again. if not you may want to raise a case at https://access.redhat.com/support/cases/

How do I get my satellite server to pull these updates down?

Run the following command:
[root@satserver ~]# satellite-sync

Has this issue been reported to Oracle? It appears to be an issue on Solaris (sparc and x86) versions of bash as well.

Oracle will take action as they see fit. Red Hat does not file CVE reports and patches to Oracle.

Debian based linux distributions are also vulnerable.

My version (bash-3.2-32.el5_9.1) is reported as vulnerable but yum update states there is no update available for bash.

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

$ sudo yum update bash
Loaded plugins: rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Skipping security plugin, no data
Setting up Update Process
No Packages marked for Update

First run:
yum clean all
Then run:
yum update bash

still no packages marked for update after running
yum clean all.

Are you installing off of a Satellite server? If so, the satellite server needs to fetch the update from Red Hat.

As root, on the Satellite server, run satellite-sync.

Or manually fetch from https://rhn.redhat.com/rhn/errata/details/Packages.do?eid=27888

I'm running a vulnerable version but also receive no updates available when running yum. When will bash-3.2-33.el5.1 be available?

You can find an rpm available here:
https://rhn.redhat.com/rhn/errata/details/Packages.do?eid=27888

my version is vulnerable too, but unable to update the bash

Running Transaction
bash-4.1.2-15.el6_5.1.x86_64 was supposed to be installed but is not!
Verifying : bash-4.1.2-15.el6_5.1.x86_64 1/2
bash-4.1.2-15.el6_4.x86_64 was supposed to be removed but is not!
Verifying : bash-4.1.2-15.el6_4.x86_64 2/2
Verifying : bash-4.1.2-15.el6_5.1.x86_64 3/2

Failed:
bash.x86_64 0:4.1.2-15.el6_4 bash.x86_64 0:4.1.2-15.el6_5.1

Complete!

Please try again as we have made several changes and more updates in the past days. If you still need assistance, please open a support case with Red Hat support.

Any chance of getting the redhat.com downloads page(s) updated to pull the patched version(s) as "latest" soon?

The bash patch for CVE-2014-6271 should be available from the customer portal if you have access to download it.

Our RHN Satellite will not have the update until the morning. Anyone have the iptables using -m string --hex-string '|28 29 20 7B|' in place? I am having trouble with the iptables command?...its been a while.

Ok I have the iptables command;

iptables --append INPUT -m string --algo kmp --hex-string '|28 29 20 7B|' --jump DROP

I realize this is not the best workaround.

okay, I did a satellite-sync, still no new bash -- what next?

The newest bash rpm for RHEL4 appears to be bash-3.0-27.el4.i386.rpm. Above states we need "bash-3.0-27.el4.2.i386.rpm. Is there a download location for that yet?

bash-4.1.2-15.el6_4.1 is not currently available via RHN. When will this be published?

We were able to update about have of our RHEL 6 systems.
Some subscribe via Satellite, some direct to RH.
Both cases, some updated, some no update available yet.
The case for Satellite, the service provider has probably not synced all yet today.
The case for direct subscriptions, is it possible that RH distribution has not completed yet?

Current date/time: Wed Sep 24 22:12:41 UTC 2014

Revised, use yum clean all first.
yum clean all
yum -y update bash

Thanks for the additional write up for this CVE item, the example alone has helped clarify the impact of this vulnerability.

Is there a download link anywhere for bash-3.0-27.el4.2 ?

it is not available via RHN with up2date -l

Only one I still need is bash-3.0-27.el4.2, not found it anywhere at this time 2300 ET

Any luck on finding the bash-3.0-27.el4.2 which I could not find anywhere on RHN?

bash.x86_64 0:4.1.2-15.el6_5.1 just showed up for us in RHN.

Hi , if i am running on older version, like RHEL 5 update 9, how do i patch just the bash?

If your system is registered with RHN, then "yum update bash" should do the job. If it is not registered/if the system does not have access to internet, then you will have to manually download the package from the customer portal and apply the fix using the rpm command

As per the errata, Package for RHEL5 is bash-3.2-33.el5.1.x86_64.rpm. If you have Extended update Support Subscription, then package would be bash-3.2-32.el5_9.2.x86_64.rpm [Both the packages mentioned here are for x86_64 arch. Refer the Errata RHSA-2014-1294 for other archs]

Well, i do not have extended update support, or i am not sure (i do have the standard) so what should i do? Can i just "yum update bash" even though i am on RHEL 5.9 or 5.10 ?

Yes, you just need to use yum update bash

I'm running a vulnerable version RHEL 6.3
There seems to be no update for this this version of RHEL listed above, nor does yum give me an update:

$ yum clean all
Loaded plugins: security
Cleaning repos: rhel-distrib
Cleaning up Everything

$ yum update bash
Loaded plugins: security
rhel-distrib | 4.0 kB 00:00
rhel-distrib/primary_db | 3.1 MB 00:00
Setting up Update Process
No Packages marked for Update

Can you check your yum repo settings. Is the box registered with Red Hat Network ?. As per the above output, it seems you are using a custom repo rhel-distrib.

You can download the package for RHEL6 from the customer portal and upgrade it as well
bash-4.1.2-15.el6_5.1.x86_64.rpm
https://access.redhat.com/downloads/content/rhel---6/x86_64/168/bash/4.1.2-15.el6_5.1/x86_64/fd431d51/package

The package that I have listed above is for x86_64 arch

I'm also having this issue... I'm using satellite and sync'd it this morning. I see it in the errata in satellite but the server server does not see the update. It sees all other updates if I do yum update but not the bash package???

yum update bash
Loaded plugins: downloadonly, product-id, rhnplugin, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
Skipping security plugin, no data
Setting up Update Process
No Packages marked for Update

RHEL 6.3 has been end of life on Jun 2014. No minor update will be released. You may need to upgrade to 6.4 or 6.5.

Is there any further comment from Red Hat regarding the tweet from Tavis Ormandy?

https://twitter.com/taviso/status/514887394294652929

-edit-

Just saw the update, thanks!

Hello

Is there a way to download the bash rpm for RHEL4 if you don't have Extended Life Support

You need to have ELS subscription to download the bash rpm package for RHEL4. Unfortunately no other way

We have ELS subscriptions for rhes4. We still can't find the needed rpms (we're using 32bit if that's relevant). I've opened a support ticket but haven't heard anything back. Do you have a link or ftp site for us?

Hello,

Sorry for the delay

Can you check if you can access the below url

bash-3.0-27.el4.2.i386.rpm
https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=1004237

Hello,

Sorry for the delay

Can you check if you can access the below url

bash-3.0-27.el4.2.i386.rpm
https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=1004237

It would seem this is not available. "We're sorry, but the package could not be found."

bash-3.0-27.el4.2.i386.rpm weare gettingthis erro

We're sorry, but the package could not be found. pls give urltodownload

Hello Jo,

Update:

Can you please contact Red Hat Technical Support. We might be able to release the packages for you.

Does actually RHSA-2014:1295 fix only CVE-2014-6271 ? What about CVE-2014-7169? Does it mean a new errata will be released soon that will fix both vulnerabilites ?

Yes thats right.

Hi, is there a rhev-h iso update planned to address this issue?

Can you please contact Red Hat Technical Support

we can't connect to internet,so we can't use yum to update the bash。
where can we get the rpm package 。

bash-3.2-24.el5

The package bash-3.2-24.el5_6.1 that you have mentioned is only included in Red Hat Enterprise Linux 5.6 LL channel. If you have the Red Hat Enterprise Linux Long Life subscription, then you can download the package from our customer portal.

If you do not have the subscription, then you can download the package bash-3.2-33.el5.1 from our customer portal if the system do not have internet access

Thanks.
if bash-3.2-33.el5.1 can fix the CVE-2014-6271 ?

Can someone confirm when the complete fix/patch for this i.e CVE-2014-7169 will be available.
Will it be released today. Any ETA?

We are working on it with the highest priority, but I'm unable to offer a specific time-frame at this time. Please contact Red Hat Technical Support for further information

Hi,

Any update.. what is the ETA for this break fix patch..

We are working on CVE-2014-7169 with the highest priority, but I'm unable to offer a specific time-frame at this time. Please contact Red Hat Technical Support for further information

Hello,

Would you please advise where can get this bash fix/patch for AIX ?

Regards,
Yahia

You probably want to contact IBM for that information.

Okay, how about a link to the SRPM for bash-3.0-27.el4.2 (RHEL4)? Planning on replacing these servers with something less primitive, but we are not ready yet.

If you have RHEL4 ELS subscription, then you should be able to download the SRPM from the customer portal. If you do not have RHEL4 ELS subscription, then contact Red Hat Technical Support

that timing?
Thanks

do you know when the complete patch will be released for this issue?

I just noticed that none of the errata SRPM packages are on ftp.redhat.com. Only the initial release SRPMS are there. Where did they go?

At least this will require no downtime apparently.

"No, a reboot of your system or any of your services is not required. This vulnerability is in the initial import of the process environment from the kernel. This only happens when Bash is started. After the update that fixes this issue is installed, such new processes will use the new code, and will not be vulnerable. Conversely, old processes will not be started again, so the vulnerability does not materialize."

do I need to restart all the services? or reboot the system?

just recevied this from RH support case when I ask if I need to reboot or restart:

"No, a reboot of your system or any of your services is not required. This vulnerability is in the initial import of the process environment from the kernel. This only happens when Bash is started. After the update that fixes this issue is installed, such new processes will use the new code, and will not be vulnerable. Conversely, old processes will not be started again, so the vulnerability does not materialize."

just recevied this from RH support case when I ask if I need to reboot or restart:

"No, a reboot of your system or any of your services is not required. This vulnerability is in the initial import of the process environment from the kernel. This only happens when Bash is started. After the update that fixes this issue is installed, such new processes will use the new code, and will not be vulnerable. Conversely, old processes will not be started again, so the vulnerability does not materialize."

I ran a satellite-sync, but it did not grab bash-3.2-33.el5 and bash-4.1.2-15.el6. Why not?

Do you have a patch for RHEL 5.2, 5.5, 5.6, and 5.8?

Please see the Products Affected: Fixed in package section.

Has anyone heard newer news about a permanent solution? For what I gather from the latest published information, the update to bash does not take care of the entire issue. Please advise.

Can Redhat kindly provide an approximate ETA to the permanent fix?

I've been following the mailing lists all day, and there is a lot of discussions (some of which I'm sure are not published) about the best way to solve the issue. Upstream and Red Hat are working on several possible solutions. For now, please be patient everyone! :-)

Thanks for a quick update. We will update you once we update the bash on our Prodcution and Test in our environment. Thanks a lot Ben and Frank.

After update bash to bash-4.1.2-15.el6_5.2,
the test result output change.

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

this is a test

I notice that following 2 lines are no more display.
|bash: warning: x: ignoring function definition attempt
|bash: error importing function definition for `x'

I know that this test result is OK, since the bash did not execute
echo vulnerable.

In other word, as of 26th/Sep, 10AM(UTC), the example in this KB still
have an old command output as good example.
It need to be replaced to new output.

$ 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

Thanks. We have the updated the article

rpm -q bash

bash-4.1.2-15.el6_5.2.i686

rpm -q --changelog bash|head

  • Thu Sep 25 2014 Ondrej Oprala ooprala@redhat.com - 4.1.2-15.2
  • CVE-2014-7169
    Resolves: #1146322

The version in changelog is 4.1.2-15.2
The version in rpm is 4.1.2-15.el6_5.2

I think these version number should be the same.

Will this affect older systems like "Red Hat Linux Advanced Server release 2.1AS (Pensacola)"? It appears to be, this is the output:

bash-2.05$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
bash: /root/.bashrc: Permission denied
this is a test

Hi,

How to solve "Public key for bash-3.2-33.el5_11.4.x86_64.rpm is not installed"?

Thanks.

yum localinstall bash-3.2-33.el5_11.4.x86_64.rpm

Loaded plugins: rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Local Package Process
Examining bash-3.2-33.el5_11.4.x86_64.rpm: bash-3.2-33.el5_11.4.x86_64
Marking bash-3.2-33.el5_11.4.x86_64.rpm as an update to bash-3.2-32.el5_9.1.x86_64
rhel-x86_64-server-5 | 1.3 kB 00:00
rhel-x86_64-server-5/primary | 5.9 MB 00:00
rhel-x86_64-server-5 16058/16058
Resolving Dependencies
--> Running transaction check
---> Package bash.x86_64 0:3.2-33.el5_11.4 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

==================================================================================================================

Package Arch Version Repository Size

Updating:
bash x86_64 3.2-33.el5_11.4 /bash-3.2-33.el5_11.4.x86_64 5.0 M

Transaction Summary

Install 0 Package(s)
Upgrade 1 Package(s)

Total size: 5.0 M
Is this ok [y/N]: y
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 37017186

Public key for bash-3.2-33.el5_11.4.x86_64.rpm is not installed

Testing patch 25 and 26 from Chet, it looks to me like this is still an incomplete fix. The third vulnerability I'd like to see fixed is the feature itself in bash that allows functions to be passed in the environment, e.g.

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

This allows an attacker to replace a command used by a bash script with arbitrary code. It is then down to an attacker to find a suitable command that the bash script (or any child shells) might call without a path component.

I can't see this being a problem for Apache custom headers (the variable name is turned to uppercase and prefixed by HTTP_), nor sudo commands if env_reset is on (the default), but this continues to be a major vulnerability for setuid/setgid scripts (S_ISUID or S_ISGID) where the environment is preserved.

One might say that importing functions from the environment is a feature, not a bug, and that the security of setuid/setgid has long been questioned. However, folk rely on it nonetheless, and bash makes it exceptionally easy to exploit. I've demonstrated a root exploit this morning using this vulnerability with the latest bash source code and patches.

Prior to Chet's patches I could also do:

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

... but with patch 25 this permutation is disallowed.

However, the latest change here from Red Hat just changes the way I have to write the exploit, but does not remove the possibility:

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

I'm not sure what the answer should be here. Remove the feature from bash and live with the few programs that break? Probably the easiest solution. Patch every OS to clear the environment on setuid/setgid and live with a few other programs that might break? That's a lot of work. Tell everyone to stop using setuid/setgid now and forever? People won't listen.

Any other suggestions ... ?

Best regards,
Mark R. Bannister.

Pages