Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 523592 (CVE-2014-6271) - <app-shells/bash-{3.1_p18-r1,3.2_p52-r1,4.0_p39-r1,4.1_p12-r1,4.2_p48-r1}: Environment handling command injection (CVE-2014-{6271,7169})
Summary: <app-shells/bash-{3.1_p18-r1,3.2_p52-r1,4.0_p39-r1,4.1_p12-r1,4.2_p48-r1}: En...
Status: RESOLVED FIXED
Alias: CVE-2014-6271
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal critical (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A1 [glsa]
Keywords:
: 523646 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-24 07:34 UTC by Alex Legler (RETIRED)
Modified: 2014-09-30 05:07 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch for CVE-2014-7169 (eol-pushback.patch,311 bytes, patch)
2014-09-25 04:24 UTC, kfm
no flags Details | Diff
Proposed bash42-049 (bash42-049,1.58 KB, patch)
2014-09-26 02:05 UTC, mike@marineau.org
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Legler (RETIRED) archtester gentoo-dev Security 2014-09-24 07:34:39 UTC
** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **

Stephane Chazelas reported via Debian:
Bash supports exporting not just shell variables, but also shell
functions to other bash instances, via the process environment to
(indirect) child processes.  Current bash versions use an environment
variable named by the function name, and a function definition
starting with “() {” in the variable value to propagate function
definitions through the environment.  The vulnerability occurs because
bash does not stop after processing the function definition; it
continues to parse and execute shell commands following the function
definition.  For example, an environment variable setting of

  VAR=() { ignored; }; /bin/id

will execute /bin/id when the environment is imported into the bash
process.  (The process is in a slightly undefined state at this point.
The PATH variable may not have been set up yet, and bash could crash
after executing /bin/id, but the damage has already happened at this
point.)
Comment 2 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-09-24 14:04:20 UTC
+*bash-4.3_p24-r2 (24 Sep 2014)
+*bash-4.2_p47-r1 (24 Sep 2014)
+*bash-4.1_p11-r1 (24 Sep 2014)
+*bash-4.0_p38-r1 (24 Sep 2014)
+*bash-3.2_p51-r1 (24 Sep 2014)
+*bash-3.1_p17-r1 (24 Sep 2014)
+
+  24 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> +bash-3.1_p17-r1.ebuild,
+  +bash-3.2_p51-r1.ebuild, +bash-4.0_p38-r1.ebuild, +bash-4.1_p11-r1.ebuild,
+  +bash-4.2_p47-r1.ebuild, -bash-4.3_p24.ebuild, -bash-4.3_p24-r1.ebuild,
+  +bash-4.3_p24-r2.ebuild, +files/bash-3.1-funcdef-import.patch,
+  +files/bash-4.3-funcdef-import.patch:
+  Security bump (bug #523592). Fixed environment handling command injection
+  (CVE-2014-6271).
+
Comment 3 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-09-24 14:09:28 UTC
Arches please test and mark stable the following versions of bash:

=app-shells/bash-3.1_p17-r1
=app-shells/bash-3.2_p51-r1
=app-shells/bash-4.0_p38-r1
=app-shells/bash-4.1_p11-r1
=app-shells/bash-4.2_p47-r1

with target KEYWORDS:
alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd

I explicitly added m68k, s390 and sh because they have stable keywords as well.
Comment 4 Agostino Sarubbo gentoo-dev 2014-09-24 15:29:55 UTC
+  24 Sep 2014; Agostino Sarubbo <ago@gentoo.org> bash-3.1_p17-r1.ebuild,
+  bash-3.2_p51-r1.ebuild, bash-4.0_p38-r1.ebuild, bash-4.1_p11-r1.ebuild,
+  bash-4.2_p47-r1.ebuild:
+  Stable for alpha/amd64/arm/ia64/ppc/ppc64/sparc/x86 wrt the security bug
+  #523592
Comment 5 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-09-24 17:23:58 UTC
+*bash-4.3_p25 (24 Sep 2014)
+*bash-4.2_p48 (24 Sep 2014)
+*bash-4.1_p12 (24 Sep 2014)
+*bash-4.0_p39 (24 Sep 2014)
+*bash-3.2_p52 (24 Sep 2014)
+*bash-3.1_p18 (24 Sep 2014)
+
+  24 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> -bash-3.1_p17-r1.ebuild,
+  +bash-3.1_p18.ebuild, -bash-3.2_p51-r1.ebuild, +bash-3.2_p52.ebuild,
+  -bash-4.0_p38-r1.ebuild, +bash-4.0_p39.ebuild, -bash-4.1_p11-r1.ebuild,
+  +bash-4.1_p12.ebuild, -bash-4.2_p47.ebuild, -bash-4.2_p47-r1.ebuild,
+  +bash-4.2_p48.ebuild, -bash-4.3_p24-r2.ebuild, +bash-4.3_p25.ebuild,
+  -files/bash-3.1-funcdef-import.patch, -files/bash-4.3-funcdef-import.patch:
+  Added official upstream fixes. Removed old. Committed straight to stable
+  where the removed ebuilds were stable.

@remaining arches:

Please mark stable the following list of versions:

=app-shells/bash-3.1_p18
=app-shells/bash-3.2_p52
=app-shells/bash-4.0_p39
=app-shells/bash-4.1_p12
=app-shells/bash-4.2_p48
Comment 6 Francisco Blas Izquierdo Riera gentoo-dev 2014-09-24 19:41:35 UTC
Wrote a blogpost with some workarounds for this issue at http://klondike.es/klog/2014/09/24/understanding-exploiting-and-preventing-cve-2014-6271-remote-code-execution-through-bash/

Gentoo's ssh with its default config is particularly affected because of this lines:
# Allow client to pass locale environment variables #367017
# Can trigger bash issue
AcceptEnv LANG LC_*

This enables the options globally and make it impossible to disable them on a per user basis unless removed.
Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-24 19:46:23 UTC
Stable for HPPA.
Comment 8 Carter Young 2014-09-24 21:01:49 UTC
*** Bug 523646 has been marked as a duplicate of this bug. ***
Comment 9 GLSAMaker/CVETool Bot gentoo-dev 2014-09-24 22:44:14 UTC
This issue was resolved and addressed in
 GLSA 201409-09 at http://security.gentoo.org/glsa/glsa-201409-09.xml
by GLSA coordinator Alex Legler (a3li).
Comment 10 Alex Legler (RETIRED) archtester gentoo-dev Security 2014-09-24 22:44:58 UTC
reopening for non security-supported arches...
Comment 11 kfm 2014-09-25 02:06:13 UTC
Alex, it looks as though the current crop of patches are half-baked.

https://twitter.com/taviso/status/514887394294652929
http://seclists.org/oss-sec/2014/q3/679
Comment 12 kfm 2014-09-25 04:05:50 UTC
"MITRE is currently using CVE-2014-7169 to track the report of the
incomplete patch, i.e., incorrect function parsing that's present in
builds that are up-to-date with the
http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-025 changes."

Source: http://seclists.org/oss-sec/2014/q3/685
Comment 13 kfm 2014-09-25 04:24:50 UTC
Created attachment 385426 [details, diff]
Patch for CVE-2014-7169

Chet Ramey's proposed patch for CVE-2014-7169. So far, it appears to be effective.
Comment 14 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-09-25 06:21:47 UTC
+*bash-4.3_p25-r1 (25 Sep 2014)
+*bash-4.2_p48-r1 (25 Sep 2014)
+*bash-4.1_p12-r1 (25 Sep 2014)
+*bash-4.0_p39-r1 (25 Sep 2014)
+*bash-3.2_p52-r1 (25 Sep 2014)
+*bash-3.1_p18-r1 (25 Sep 2014)
+
+  25 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> +bash-3.1_p18-r1.ebuild,
+  +bash-3.2_p52-r1.ebuild, +bash-4.0_p39-r1.ebuild, +bash-4.1_p12-r1.ebuild,
+  +bash-4.2_p48-r1.ebuild, +bash-4.3_p25-r1.ebuild,
+  +files/bash-eol-pushback.patch:
+  Another security bump for CVE-2014-7169 (bug #523592).
+

Readded arches. Please test and mark stable the following bash versions:

=app-shells/bash-3.1_p18-r1
=app-shells/bash-3.2_p52-r1
=app-shells/bash-4.0_p39-r1
=app-shells/bash-4.1_p12-r1
=app-shells/bash-4.2_p48-r1

Target KEYWORDS are:
alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
Comment 15 Agostino Sarubbo gentoo-dev 2014-09-25 07:33:06 UTC
+  25 Sep 2014; Agostino Sarubbo <ago@gentoo.org> bash-3.1_p18-r1.ebuild,                                                                                                                                                                                                      
+  bash-3.2_p52-r1.ebuild, bash-4.0_p39-r1.ebuild, bash-4.1_p12-r1.ebuild,                                                                                                                                                                                                     
+  bash-4.2_p48-r1.ebuild:                                                                                                                                                                                                                                                     
+  Stable for alpha/amd64/arm/ia64/ppc/ppc64/sparc/sh/x86 wrt the security bug                                                                                                                                                                                                 
+  #523592
Comment 16 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-25 10:10:44 UTC
Stable for HPPA.
Comment 17 Raúl Porcel (RETIRED) gentoo-dev 2014-09-25 11:01:29 UTC
arm64/m68k/s390/sh stable
Comment 18 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-09-25 11:32:53 UTC
+  25 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> -bash-3.1_p17.ebuild,
+  -bash-3.1_p18.ebuild, -bash-3.2_p51.ebuild, -bash-3.2_p52.ebuild,
+  -bash-4.0_p38.ebuild, -bash-4.0_p39.ebuild, -bash-4.1_p11.ebuild,
+  -bash-4.1_p12.ebuild, -bash-4.2_p45.ebuild, -bash-4.2_p48.ebuild,
+  -bash-4.3_p25.ebuild:
+  Removed vulnerable versions.
Comment 19 Tobias Klausmann (RETIRED) gentoo-dev 2014-09-25 11:38:44 UTC
Still vulnerable:

$ env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

(from https://twitter.com/taviso/status/514887394294652929)
Comment 20 Philip Taffner 2014-09-25 11:41:59 UTC
Nope. Current patch works. See comments above.
Comment 21 Andrew Savchenko gentoo-dev 2014-09-25 11:45:03 UTC
(In reply to Tobias Klausmann from comment #19)
> Still vulnerable:
> 
> $ env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln"
> ]] && echo "still vulnerable :("
> 
> (from https://twitter.com/taviso/status/514887394294652929)

Vulnerable with 4.2_p48, but not 4.2_p48-r1:

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
echo vuln
cat: echo: No such file or directory
Comment 22 Tobias Klausmann (RETIRED) gentoo-dev 2014-09-25 12:01:50 UTC
Ignore me, I'm an idiot.
Comment 23 GLSAMaker/CVETool Bot gentoo-dev 2014-09-25 14:00:23 UTC
This issue was resolved and addressed in
 GLSA 201409-10 at http://security.gentoo.org/glsa/glsa-201409-10.xml
by GLSA coordinator Tobias Heinlein (keytoaster).
Comment 24 Hanno Böck gentoo-dev 2014-09-25 17:54:17 UTC
I'm not sure if this is better kept in a new bug report, but wanted to share this: Redhat devs just posted to oss sec that they found more issues in the function parser, two out of bound memory errors: http://seclists.org/oss-sec/2014/q3/712

I'm not sure how serious.
Comment 25 kfm 2014-09-25 22:41:24 UTC
(In reply to Hanno Boeck from comment #24)
> I'm not sure if this is better kept in a new bug report, but wanted to share
> this: Redhat devs just posted to oss sec that they found more issues in the
> function parser, two out of bound memory errors:
> http://seclists.org/oss-sec/2014/q3/712
> 
> I'm not sure how serious.

I've filed bug 523742 for these two bugs.
Comment 26 Chandler Paul 2014-09-25 22:59:51 UTC
Are we sure this has been fixed? I'm running the latest version of bash available from portage, app-shells/bash-4.2_p48-r1, and I've tried one of the vulnerability tests on here: https://shellshocker.net/

The vulnerability test is the second one listed, here's my results:

meerkat%:~> env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
date
Thu Sep 25 18:52:16 EDT 2014
Comment 27 kfm 2014-09-25 23:04:17 UTC
(In reply to Chandler Paul from comment #26)
> Are we sure this has been fixed? I'm running the latest version of bash
> available from portage, app-shells/bash-4.2_p48-r1, and I've tried one of
> the vulnerability tests on here: https://shellshocker.net/
> 
> The vulnerability test is the second one listed, here's my results:
> 
> meerkat%:~> env X='() { (a)=>\' sh -c "echo date"; cat echo
> sh: X: line 1: syntax error near unexpected token `='
> sh: X: line 1: `'
> sh: error importing function definition for `X'
> date
> Thu Sep 25 18:52:16 EDT 2014

Make sure that your instance of bash has been started afresh after upgrading. If in doubt, use app-admin/lib_users to check for stale instances.
Comment 28 Chandler Paul 2014-09-25 23:36:02 UTC
(In reply to Kerin Millar from comment #27)
> (In reply to Chandler Paul from comment #26)
> > Are we sure this has been fixed? I'm running the latest version of bash
> > available from portage, app-shells/bash-4.2_p48-r1, and I've tried one of
> > the vulnerability tests on here: https://shellshocker.net/
> > 
> > The vulnerability test is the second one listed, here's my results:
> > 
> > meerkat%:~> env X='() { (a)=>\' sh -c "echo date"; cat echo
> > sh: X: line 1: syntax error near unexpected token `='
> > sh: X: line 1: `'
> > sh: error importing function definition for `X'
> > date
> > Thu Sep 25 18:52:16 EDT 2014
> 
> Make sure that your instance of bash has been started afresh after
> upgrading. If in doubt, use app-admin/lib_users to check for stale instances.

It looks like I had a file called `echo` leftover from the test before my bash version was patched, and that's why it was still giving the date properly. Mystery solved, sorry about that!
Comment 29 GLSAMaker/CVETool Bot gentoo-dev 2014-09-26 00:02:24 UTC
CVE-2014-7169 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7169):
  GNU Bash through 4.3 bash43-025 processes trailing strings after certain
  malformed function definitions in the values of environment variables, which
  allows remote attackers to write to files or possibly have unknown other
  impact via a crafted environment, as demonstrated by vectors involving the
  ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in
  the Apache HTTP Server, scripts executed by unspecified DHCP clients, and
  other situations in which setting the environment occurs across a privilege
  boundary from Bash execution.  NOTE: this vulnerability exists because of an
  incomplete fix for CVE-2014-6271.

CVE-2014-6271 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-6271):
  GNU Bash through 4.3 processes trailing strings after function definitions
  in the values of environment variables, which allows remote attackers to
  execute arbitrary code via a crafted environment, as demonstrated by vectors
  involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid
  modules in the Apache HTTP Server, scripts executed by unspecified DHCP
  clients, and other situations in which setting the environment occurs across
  a privilege boundary from Bash execution.
Comment 30 mike@marineau.org 2014-09-26 02:05:27 UTC
Created attachment 385486 [details, diff]
Proposed bash42-049

The proposed release is slightly different from the one used here.

http://www.openwall.com/lists/oss-security/2014/09/26/1
Comment 31 kfm 2014-09-26 17:58:35 UTC
Here's a post that is worth watching:

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

I tried the example there on two of my hosts. The first is running the stock 4.2_p48-r1 package.

  kerin@host1 ~ $ env ls='() { echo vulnerable; }' bash -c ls
  vulnerable

The second host is running a bash ebuild from my overlay that is exactly the same except that it also includes the two patches from bug 523742.

  kerin@host2 ~ $ env ls='() { echo vulnerable; }' bash -c ls
  noop

Now, trying as root ...

  root@host1 ~ # env ls='() { echo vulnerable; }' bash -c ls
  vulnerable

  root@host2 ~ # env ls='() { echo vulnerable; }' bash -c ls
  ... proceeds to execute ls normally ...

I'm not familiar with bash internals but, from a quick glance, it looks as though bash is supposed to avoid importing functions from variables if it is running in privileged mode (set -p) or is running with setuid.

Unfortunately, it doesn't seem to abide by these rules. Here's an example:

  kerin@host1 ~ $ stat -c%a /usr/local/bin/helloworld
  6755
  kerin@host1 ~ $ helloworld
  Hello World
  kerin@host1 ~ $ env echo='() { /bin/echo "Goodbye World"; }' helloworld
  Goodbye World

I have no idea why the inclusion of the patches from bug 523742 results in a different outcome. Nor do I know where that odd "noop" response comes from (it may be a gettext goof).
Comment 32 kfm 2014-09-26 23:41:39 UTC
Regarding my previous comment, I misunderstood the contraints. Bash will indeed refrain from importing functions, if set -p is enabled or the shell itself is running setuid. This is unrelated to whether the setuid bit is enabled on a shell script (which has no effect in any case). The list post that I mentioned can be disregarded. Sorry about that, bug watchers.

The breaking behaviour caused by the Red Hat patches is still a concern, but the discussion for that belongs in the other bug.
Comment 33 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-09-27 05:12:34 UTC
+*bash-4.3_p26 (27 Sep 2014)
+*bash-4.2_p49 (27 Sep 2014)
+*bash-4.1_p13 (27 Sep 2014)
+*bash-4.0_p40 (27 Sep 2014)
+*bash-3.2_p53 (27 Sep 2014)
+*bash-3.1_p19 (27 Sep 2014)
+
+  27 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> -bash-3.1_p18-r1.ebuild,
+  +bash-3.1_p19.ebuild, -bash-3.2_p52-r1.ebuild, +bash-3.2_p53.ebuild,
+  -bash-4.0_p39-r1.ebuild, +bash-4.0_p40.ebuild, -bash-4.1_p12-r1.ebuild,
+  +bash-4.1_p13.ebuild, -bash-4.2_p48-r1.ebuild, +bash-4.2_p49.ebuild,
+  -bash-4.3_p25-r1.ebuild, +bash-4.3_p26.ebuild,
+  -files/bash-eol-pushback.patch:
+  Added official upstream fixes for CVE-2014-7169. Removed old. Committed
+  straight to stable.
+
Comment 34 Jose Maldonado 2014-09-30 04:45:39 UTC
Well I have bash 4.2_p50, and execute this command

env X='() { (a)=>\' sh -c "echo vulnerable"; bash -c "echo Fallo 2 parcheado"

The output is this:

vulnerable
Fallo 2 parcheado


Problems??
Comment 35 Jose Maldonado 2014-09-30 05:07:46 UTC
(In reply to Jose Maldonado from comment #34)
> Well I have bash 4.2_p50, and execute this command
> 
> env X='() { (a)=>\' sh -c "echo vulnerable"; bash -c "echo Fallo 2 parcheado"
> 
> The output is this:
> 
> vulnerable
> Fallo 2 parcheado
> 
> 
> Problems??

Forget it...it's bad formated for the line :/

PD: I did not wrote.