** 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.)
public via https://anonscm.debian.org/viewvc/secure-testing/data/DSA/list?revision=29000&view=markup
+*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). +
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.
+ 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
+*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
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.
Stable for HPPA.
*** Bug 523646 has been marked as a duplicate of this bug. ***
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).
reopening for non security-supported arches...
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
"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
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.
+*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
+ 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
arm64/m68k/s390/sh stable
+ 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.
Still vulnerable: $ env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :(" (from https://twitter.com/taviso/status/514887394294652929)
Nope. Current patch works. See comments above.
(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
Ignore me, I'm an idiot.
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).
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.
(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.
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
(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.
(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!
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.
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
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).
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.
+*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. +
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??
(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.
