Summary: | <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}) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Alex Legler (RETIRED) <a3li> | ||||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | critical | CC: | alexander, base-system, bircoph, dan, dryatu, ecyoung, hanno, kfm, luke, sabel | ||||||
Priority: | Normal | ||||||||
Version: | unspecified | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | A1 [glsa] | ||||||||
Package list: | Runtime testing required: | --- | |||||||
Attachments: |
|
Description
Alex Legler (RETIRED)
![]() ![]() ![]() 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 Stable for HPPA. 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. |