Bug 1146319 - (CVE-2014-7169) CVE-2014-7169 bash: code execution via specially-crafted environment (Incomplete fix for CVE-2014-6271)
CVE-2014-7169 bash: code execution via specially-crafted environment (Incompl...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20140924,repo...
: Reopened, Security
Depends On: 1146321 1146322 1146323 1146324 1146325 1146326 1146349 1146350 1146990 1146991 1148137 1148138 1148152 1148153 1148771
Blocks: 1141602
  Show dependency treegraph
 
Reported: 2014-09-24 22:05 EDT by Huzaifa S. Sidhpurwala
Modified: 2014-11-17 13:47 EST (History)
93 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It was found that the fix for CVE-2014-6271 was incomplete, and Bash still allowed certain characters to be injected into other environments via specially crafted environment variables. An attacker could potentially use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-22 00:42:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
variables-affix-4.2.patch (5.13 KB, patch)
2014-09-27 06:25 EDT, Florian Weimer
no flags Details | Diff
bash42-049 (1.22 KB, patch)
2014-09-27 06:29 EDT, Florian Weimer
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1207723 None None None Never
Red Hat Knowledge Base (Article) 1200223 None None None Never

  None (edit)
Description Huzaifa S. Sidhpurwala 2014-09-24 22:05:41 EDT
It was found the patch applied to fix CVE-2014-6271 was incomplete and could still allow some characters to be injected into another environment. An attacker could use this flaw to bypass some security restrictions, such as access files which he previously does not have access to etc (Standard file system permissions and selinux if enabled prevail though). There is no proof that this flaw could be used to execute arbitrary code, if it does it should be very difficult to exploit and depend on the specific configuration of the service.

Reference:

http://www.openwall.com/lists/oss-security/2014/09/24/40
https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23
Comment 2 Huzaifa S. Sidhpurwala 2014-09-24 22:09:11 EDT
Created bash tracking bugs for this issue:

Affects: fedora-all [bug 1146326]
Comment 3 Tavis Ormandy 2014-09-24 22:33:24 EDT
The case of system("foo") would depend on service configuration and what foo does. However, the case of system("foo" + shellescape(bar)), which seems like it must be common, is trivially exploitable, no?
Comment 4 Huzaifa S. Sidhpurwala 2014-09-24 22:43:32 EDT
(In reply to Tavis Ormandy from comment #3)
> The case of system("foo") would depend on service configuration and what foo
> does. However, the case of system("foo" + shellescape(bar)), which seems
> like it must be common, is trivially exploitable, no?

In what use case? ssh+ForceCommand/mod_cgi?
Comment 5 Huzaifa S. Sidhpurwala 2014-09-24 22:45:40 EDT
MITRE has assigned CVE-2014-7169 and rejected CVE-2014-3659.
We shall be using CVE-2014-7169 for this issue now.

http://www.openwall.com/lists/oss-security/2014/09/25/8
Comment 6 Tavis Ormandy 2014-09-24 22:52:54 EDT
cgi, even the example in the PHP manual looks vulnerable

http://php.net/manual/en/function.escapeshellarg.php

(Ignoring that system("foo") could still be exploitable, depending on configuration)
Comment 7 Huzaifa S. Sidhpurwala 2014-09-24 23:06:38 EDT
(In reply to Tavis Ormandy from comment #6)
> cgi, even the example in the PHP manual looks vulnerable
> 
> http://php.net/manual/en/function.escapeshellarg.php
> 
> (Ignoring that system("foo") could still be exploitable, depending on
> configuration)

Yeah. Upstream just posted a patch, now to see if it can be bypassed :)

http://www.openwall.com/lists/oss-security/2014/09/25/10
Comment 10 john.haxby@oracle.com 2014-09-25 04:21:21 EDT
It's a small thing, but people do tend to rely on the CVE number being in the bash changelog.   Can you make sure it's there this time please?
Comment 27 EJ Vincent 2014-09-25 19:34:26 EDT
+1 Please provide CVE ID number in bash package changelog. Thank you very much for your hard work and diligence.
Comment 29 errata-xmlrpc 2014-09-25 21:46:53 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7
  Red Hat Enterprise Linux 5

Via RHSA-2014:1306 https://rhn.redhat.com/errata/RHSA-2014-1306.html
Comment 31 Arun S A G 2014-09-26 02:08:00 EDT
Can some one upload/attach the patches just like rhbz:1141597 here please?
Comment 33 Martin Prpic 2014-09-26 03:25:52 EDT
IssueDescription:

It was found that the fix for CVE-2014-6271 was incomplete, and Bash still allowed certain characters to be injected into other environments via specially crafted environment variables. An attacker could potentially use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.
Comment 34 Fedora Update System 2014-09-26 05:00:39 EDT
bash-4.2.48-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 35 Fedora Update System 2014-09-26 05:02:47 EDT
bash-4.2.48-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 39 Bhagirath Hapse 2014-09-26 07:51:25 EDT
I am able to see here (https://access.redhat.com/articles/1200223) that the fix for CVE-2014-6271 is provided for RHEL 4,5,6 and 7.
Whereas on below link (https://access.redhat.com/security/cve/CVE-2014-7169) the fix for CVE-2014-7169 is only available for RHEL 5,6 and 7.
May I know why? I am looking for the fix of CVE-2014-7169 for RHEL 4 as well.
Please reply.
Comment 41 errata-xmlrpc 2014-09-26 13:58:27 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.4 EUS - Server and Compute Node Only
  Red Hat Enterprise Linux 6.2 AUS
  Red Hat Enterprise Linux 5.6 Long Life
  Red Hat Enterprise Linux 5.9 EUS - Server Only
  Red Hat Enterprise Linux 4 Extended Lifecycle Support

Via RHSA-2014:1311 https://rhn.redhat.com/errata/RHSA-2014-1311.html
Comment 42 Mike 2014-09-26 15:06:44 EDT
This patch breaks atd if functions are in your environment.  atd will generate an invalid bash script.

bash-4.1$ function hi() { echo 'hello'; }
bash-4.1$ hi
hello
bash-4.1$ export -f hi
bash-4.1$ echo "echo 'ha'" | at now
job 65 at 2014-09-26 14:57

email comes in:
sh: line 32: syntax error near unexpected token `=\(\)\ {\ \ echo\ \'hello\'"
"}'
sh: line 32: `"}; export BASH_FUNC_hi()'
Comment 43 Akemi Yagi 2014-09-26 16:31:14 EDT
(In reply to Mike from comment #42)
> This patch breaks atd if functions are in your environment.  atd will
> generate an invalid bash script.
> 
> bash-4.1$ function hi() { echo 'hello'; }
> bash-4.1$ hi
> hello
> bash-4.1$ export -f hi
> bash-4.1$ echo "echo 'ha'" | at now
> job 65 at 2014-09-26 14:57
> 
> email comes in:
> sh: line 32: syntax error near unexpected token `=\(\)\ {\ \ echo\ \'hello\'"
> "}'
> sh: line 32: `"}; export BASH_FUNC_hi()'

Someone posted a fix here:

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

[quote]
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

[/quote]
Comment 44 Paul Victor Novarese 2014-09-26 16:40:57 EDT
I'm not sure if I'd call that a "fix."  It might be a workaround, maybe, but it very well could break things.
Comment 45 Jerry Uanino 2014-09-26 16:42:33 EDT
(In reply to Akemi Yagi from comment #43)
> (In reply to Mike from comment #42)
> > This patch breaks atd if functions are in your environment.  atd will
> > generate an invalid bash script.
> > 
> > bash-4.1$ function hi() { echo 'hello'; }
> > bash-4.1$ hi
> > hello
> > bash-4.1$ export -f hi
> > bash-4.1$ echo "echo 'ha'" | at now
> > job 65 at 2014-09-26 14:57
> > 
> > email comes in:
> > sh: line 32: syntax error near unexpected token `=\(\)\ {\ \ echo\ \'hello\'"
> > "}'
> > sh: line 32: `"}; export BASH_FUNC_hi()'
> 
> Someone posted a fix here:
> 
> https://access.redhat.com/articles/1200223#comment-824453
> 
> [quote]
> 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
> 
> [/quote]

If you avoid having the function set, then yes this would fix it. However, in our case we actually have functions set that we need.
Comment 46 Akemi Yagi 2014-09-26 16:44:34 EDT
Actually, I meant to put a " " around the 'fix'.
Comment 47 errata-xmlrpc 2014-09-26 17:28:26 EDT
This issue has been addressed in the following products:

  S-JIS for Red Hat Enteprise Linux 6
  S-JIS for Red Hat Enteprise Linux 5

Via RHSA-2014:1312 https://rhn.redhat.com/errata/RHSA-2014-1312.html
Comment 49 Eric Blake 2014-09-27 02:42:18 EDT
Can someone please update https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/ and/or https://access.redhat.com/articles/1200223 to mention that:

Red Hat/Fedora builds that include the fix for CVE-2014-7169 are also immune to CVE-2014-7186/CVE-2014-7187, but people building upstream bash are not yet immune (because Red Hat has added patches that are not yet officially upstream)

and give pointers of how to test whether bash is still vulnerable to shellshock attacks, such as using some of the test scripts in this mail for exposing whether a shell is vulnerable to CVE-2014-7186:
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html

I'm worried that people will be lulled into a false sense of security ("I've applied both upstream bash patches, therefore I must be secure") when in reality they are still vulnerable to ShellShock until either the entire bash parser is audited to be bug-free (difficult) or until bash is fixed to avoid ever calling the bash parser on arbitrary contents of normal environment variables (easy, as done in the Red Hat patch).
Comment 50 Fedora Update System 2014-09-27 06:08:13 EDT
bash-4.3.25-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 51 Florian Weimer 2014-09-27 06:25:33 EDT
Created attachment 941826 [details]
variables-affix-4.2.patch

This is the hardening patch which adds function name mangling.  It does not fix this bug (CVE-2014-7169), but it makes exploitation over the network impossible via the known vectors.  The latter also applies to function parser bugs which may be discovered in the future.

Erratas released by Red Hat which fix CVE-2014-7169 (using the upstream patch) also contain this hardening.  Other vendors may have only applied the upstream fix for CVE-2014-7169, without this hardening patch.
Comment 52 Florian Weimer 2014-09-27 06:29:06 EDT
Created attachment 941827 [details]
bash42-049

Upstream fix from <ftp://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-049>, and included in our packages.

Note: Some versions of patch have bugs in the offset detection for context diffs such as this one, and may misapply the patch in a way the resulting source code still compiles, but without actually fixing the vulnerability.
Comment 53 Florian Weimer 2014-09-27 13:40:17 EDT
(In reply to Mike from comment #42)
> This patch breaks atd if functions are in your environment.  atd will
> generate an invalid bash script.

This is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1147043
Comment 54 Nickolay Bunev 2014-09-27 17:04:05 EDT
Florian,
Does your patch fixes the parsing issue which Michal Zalewski found (CVE-2014-6277) beforehand?
Comment 57 Vincent Danen 2014-09-29 10:26:58 EDT
Statement:

(none)
Comment 64 errata-xmlrpc 2014-10-02 14:43:55 EDT
This issue has been addressed in the following products:

  RHEV Manager version 3.4

Via RHSA-2014:1354 https://rhn.redhat.com/errata/RHSA-2014-1354.html
Comment 65 Tomas Hoger 2014-10-03 03:29:15 EDT
@BGROSLIER, please do not change the status of this bug.
Comment 66 errata-xmlrpc 2014-11-17 13:11:28 EST
This issue has been addressed in the following products:

  S-JIS for RHEL 5.9.Z

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

Note You need to log in before you can comment on or make changes to this bug.