Created attachment 385460 [details, diff] variables-affix.patch In the wake of the issues described by bug 523592, analysis performed by Red Hat uncovered two out-of-bounds array access issues in the Bash parser: http://seclists.org/oss-sec/2014/q3/712 These patches have been deemed fit for stable inclusion in Debian, as indicated in this advisory: http://permalink.gmane.org/gmane.linux.debian.user.security.announce/3197 There are no CVE identifiers for these bugs that I am aware of. I would suggest that these patches also be incorporated by Gentoo. Because the fix for CVE-2014-7169 was fast-tracked, resulting in a rapid revision bump and a newly issued GLSA, it may (or may not) be considered preferable to wait until an official patch for said CVE materializes before bumping once again - depending on how severe this bug is considered to be. This is an excerpt from Debian's patch series, from which I am attaching the latter two patches: CVE-2014-6271.diff CVE-2014-7169.diff variables-affix.patch parser-oob.patch These are known to apply to bash-4.2. They may also apply to other versions.
Created attachment 385462 [details, diff] parser-oob.patch
CVE's Being Requested in this URL: http://seclists.org/oss-sec/2014/q3/730 Upstream is aware of this and was cc'd as part of the information. It is my opinion that we should wait for upstream. At this time I have not seen attack vectors anyway so for now A3
Yeah, I'm also in favor of waiting for official upstream patches here.
Is someone able to reproduce this bug with our bash versions?
bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: warning: here-document at line 2 delimited by end-of-file (wanted `EOF') bash: line 2: make_here_document: bad instruction type 33 Segmentation fault I think "Segmentation fault" means "I reproduced it". Can't reproduce the other example, just gives me a syntax error.
(In reply to Hanno Boeck from comment #5) > I think "Segmentation fault" means "I reproduced it". Can't reproduce the > other example, just gives me a syntax error. In the case of the second example, the poster says that the issue is visible when running the sample code and using address sanitizer. From that, I would assume that >=gcc-4.8 is used and that bash is built with -fsanitize=address.
I get: ago@willoughby ~ $ bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') bash: warning: here-document at line 0 delimited by end-of-file (wanted `EOF') ago@willoughby ~ $ qlist -ICv | grep bash app-shells/bash-4.2_p48-r1
Augusto, try chaining <<EOF more times. I can hit the issue in bash-4.2_p48-r1 but I have to specify it at least 79 times.
Apologies, I mean Agostino.
Here's an example. Fully reproducible on this box. kerin@li356-58 ~ $ bash -c "true $(printf '<<EOF %.0s' {1..79})" Segmentation fault
While the patches address the test case described above, I've discovered an odd side effect that I am currently unable to attribute to anything else. https://bugs.gentoo.org/show_bug.cgi?id=523592#c31
lcamtuf has postet a drastic warning about further parser bugs: http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unofficial-patch-now.html Given the severity this might have I suggest we don't wait for official upstream patches but for now apply both parser-oob and variables-affix. I'm now deploying them manually for my servers, here's our ebuild (basically just the last stable from portage + the two patches from redhat rediffed): https://svn.schokokeks.org/repos/overlay/trunk/app-shells/bash/
(In reply to Hanno Boeck from comment #12) > lcamtuf has postet a drastic warning about further parser bugs: > http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unofficial-patch-now.html > > Given the severity this might have I suggest we don't wait for official > upstream patches but for now apply both parser-oob and variables-affix. > I'm now deploying them manually for my servers, here's our ebuild (basically > just the last stable from portage + the two patches from redhat rediffed): > https://svn.schokokeks.org/repos/overlay/trunk/app-shells/bash/ Normally, I would be in full agreement. The only problem is that they have a worrying side-effect, as mentioned above. I should have posted the details here originally and shall do so once I've determined which patch is responsible.
I've done some more testing and can confirm that the fix for CVE-2014-7186 (variables-affix.patch) completely breaks the ability for bash to source functions from the environment. As much as some may consider this to be a misfeature, such breakage is unacceptable. Below is a full breakdown of the tests that I performed. Package/patch combinations: [A] bash-4.2_p49 [B] bash-4.2_p49 + variables_affix + parser_oob [C] bash_4.2_p49 + variables_affix [D] bash_4.2_p49 + parser_oob Test cases: [1] # env propagated_func='() { echo "propagated_func() called"; }' bash -c propagated_func [2] $ env propagated_func='() { echo "propagated_func() called"; }' bash -c propagated_func Test results (stdout/stderr): [A1] propagated_func() called [A2] propagated_func() called [B1] bash: propagated_func: command not found [B2] bash: propagated_func: command not found [C1] bash: propagated_func: command not found [C2] bash: propagated_func: command not found [D1] propagated_func() called [D2] propagated_func() called NOTE: The reason that I tested in both root and non-root context is that I was able to make bash produce a very odd-response during a previous test, per comment 11. Results [B1] through [C2] are improper because I was not running bash in protected mode, nor was it running setuid. I'm going to report this to Huzaifa Sidhpurwala.
With variables-affix.patch, this works instead ... # env 'BASH_FUNC_propagated_func()'='() { echo "propagated_func() called"; }' bash -c propagated_func propagated_func() called
I've emailed Red Hat asking for confirmation that this change won't break any existing applications. I can't really see how it helps because it simply changes the naming convention. In any case, I'll comment again should I hear anything in response.
@Kerin Millar: This patch is supposed to disable the function import feature in its previous way. It will break things, however choosing between a remotely exploitable system and some breakage with a very uncommon feature I choose the (very rare) breakage. Changing the naming convention helps because an attacker cannot set arbitrary variables, he can only set very special ones (like HTTP_REFERRER etc.). Please read the lengthy discussion on oss-security about it, this is really not the place here. Chet Ramey has now published a patch which I think is similar to Florian Weimer's one, however it has a different suffix-syntax: http://www.openwall.com/lists/oss-security/2014/09/28/1 Please note that this does not fix the two out-of-bound-issues, if this patch is taken these should be applied separately.
(In reply to Hanno Boeck from comment #17) > @Kerin Millar: This patch is supposed to disable the function import feature > in its previous way. It will break things, however choosing between a > remotely exploitable system and some breakage with a very uncommon feature I > choose the (very rare) breakage. Absolutely. > Changing the naming convention helps > because an attacker cannot set arbitrary variables, he can only set very > special ones (like HTTP_REFERRER etc.). Please read the lengthy discussion > on oss-security about it, this is really not the place here. Thanks. I understand now.
https://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-050 I think this is the upstream fix, right ?
+*bash-4.3_p27 (28 Sep 2014) +*bash-4.2_p50 (28 Sep 2014) +*bash-4.1_p14 (28 Sep 2014) +*bash-4.0_p41 (28 Sep 2014) +*bash-3.2_p54 (28 Sep 2014) +*bash-3.1_p20 (28 Sep 2014) + + 28 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> +bash-3.1_p20.ebuild, + +bash-3.2_p54.ebuild, +bash-4.0_p41.ebuild, +bash-4.1_p14.ebuild, + +bash-4.2_p50.ebuild, -bash-4.3_p26.ebuild, +bash-4.3_p27.ebuild: + Security bump. Another bunch of shellshock fixes. This time for + CVE-2014-7186, CVE-2014-7187 and CVE-2014-6277. + Arches, please test and mark stable the following bash versions: =app-shells/bash-3.1_p20 =app-shells/bash-3.2_p54 =app-shells/bash-4.0_p41 =app-shells/bash-4.1_p14 =app-shells/bash-4.2_p50 Target KEYWORDS are: alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd I explicitly added arm64, m68k, s390 and sh because they have stable keywords as well.
Lars, the official patchlevels do not address CVE-2014-7187. kerin@li356-58 ~ $ qlist -Iv bash app-shells/bash-4.2_p50 kerin@li356-58 ~ $ bash -c "true $(printf '<<EOF %.0s' {1..79})" Segmentation fault I applied Hanno's cleanly re-diffed parser-oob.patch to prevent this crash from occurring. I would suggest doing the same.
(In reply to Kerin Millar from comment #21) > Lars, the official patchlevels do not address CVE-2014-7187. > > kerin@li356-58 ~ $ qlist -Iv bash > app-shells/bash-4.2_p50 > kerin@li356-58 ~ $ bash -c "true $(printf '<<EOF %.0s' {1..79})" > Segmentation fault > > I applied Hanno's cleanly re-diffed parser-oob.patch to prevent this crash > from occurring. I would suggest doing the same. Yeah, I relied on a mail from Eric Blake [1] when writing this. Further upstream patches will come it's just a matter of time. We shoult still stabilize these versions as they fix a severe aspect of the shellshock problem. [1] http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00288.html
(In reply to Lars Wendler (Polynomial-C) from comment #20) > Arches, please test and mark stable the following bash versions: > > =app-shells/bash-3.1_p20 > =app-shells/bash-3.2_p54 > =app-shells/bash-4.0_p41 > =app-shells/bash-4.1_p14 > =app-shells/bash-4.2_p50 > > Target KEYWORDS are: > alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 > ~amd64-fbsd ~sparc-fbsd ~x86-fbsd All five stable for alpha. (Keeping CC around because likely there will be more stablings).
+ 29 Sep 2014; Agostino Sarubbo <ago@gentoo.org> bash-3.1_p20.ebuild, + bash-3.2_p54.ebuild, bash-4.0_p41.ebuild, bash-4.1_p14.ebuild, + bash-4.2_p50.ebuild: + Stable for amd64/arm/ia64/ppc/ppc64/sparc/sh/x86 wrt the security bug #523742 CC back all arches if we need to do something else.
Stable for HPPA.
Still vilerable to CVE-2014-7186 (redir_stack bug). Check with: https://github.com/hannob/bashcheck
(In reply to Lars Wendler (Polynomial-C) from comment #22) > (In reply to Kerin Millar from comment #21) > > Lars, the official patchlevels do not address CVE-2014-7187. > > > > kerin@li356-58 ~ $ qlist -Iv bash > > app-shells/bash-4.2_p50 > > kerin@li356-58 ~ $ bash -c "true $(printf '<<EOF %.0s' {1..79})" > > Segmentation fault > > > > I applied Hanno's cleanly re-diffed parser-oob.patch to prevent this crash > > from occurring. I would suggest doing the same. > > Yeah, I relied on a mail from Eric Blake [1] when writing this. Further > upstream patches will come it's just a matter of time. We shoult still > stabilize these versions as they fix a severe aspect of the shellshock > problem. > I don't see a good argument why we are stabilizing vulnerable bash versions. Even the commit message does not look right regarding comment #c26. I advise people to use the version hannob has linked, not the tree version.
Using https://github.com/hannob/bashcheck . [root@fuji-02 /dev/shm]# eix ^bash$ [I] app-shells/bash Available versions: (3.1) 3.1_p19 3.1_p20 (3.2) 3.2_p53 3.2_p54 (4.0) 4.0_p40 4.0_p41 (4.1) 4.1_p13 4.1_p14 (0) 4.2_p49 4.2_p50 **4.3_p27 {afs bashlogger examples mem-scramble +net nls plugins +readline vanilla} Installed versions: 4.2_p50(04:04:11 PM 09/29/2014)(net nls plugins readline -afs -bashlogger -examples -mem-scramble -vanilla) Homepage: http://tiswww.case.edu/php/chet/bash/bashtop.html Description: The standard GNU Bourne again shell [root@fuji-02 /dev/shm]# [root@fuji-02 /dev/shm]# ./bashcheck Not vulnerable to CVE-2014-6271 (original shellshock) Not vulnerable to CVE-2014-7169 (taviso bug) ./bashcheck: line 18: 20231 Segmentation fault bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null Vulnerable to CVE-2014-7186 (redir_stack bug) Test for CVE-2014-7187 not reliable without address sanitizer Variable function parser inactive, likely safe from unknown parser bugs Thanks.
In summary, the latest available version of bash in portage addresses neither of the two vulnerabilities this bug concerns. Several people have already pointed out that CVE-2014-7186 still applies. I installed gcc-4.8 and exported CFLAGS="-fsanitize=address" in order to check for CVE-2014-7187. This was the result: # emerge -q1 =bash-4.2_p50 >/dev/null # qlist -Iv bash app-shells/bash-4.2_p50 # bash -c "$(for i in {1..200}; do echo -n "for x$i in; do :;"; done; for i in {1..200}; do echo -n "done;";done)" 2>&1 | head -n2 ================================================================= ==28323== ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000747ce0 at pc 0x4286d2 bp 0x7fffd17eb310 sp 0x7fffd17eb308 Gentoo has dropped the ball here. Please accept the parser-oob patch as other distributions have - Red Hat, Debian, Ubuntu and Arch among them.
What is the decision from Gentoo developers on this? I second the suggestions from the previous comments to have gentoo add the parser-oob patch to address CVE 7186/7187.
Alright, before the nagging escalates, here is what Chet Ramey, the bash upstram maintainer/developer, told me via email regarding this problem: > If you have applied bash43-027, these bugs are local problems, so if you've > already got the function name encoding patch in place you should be safe. bash43-027 contains the same fix as bash42-050, bash41-014, bash40-041, bash32-054 and bash31-020. So our bash-4.2_p50 is as (un)safe as bash-4.3_p27 at this moment.
(In reply to Lars Wendler (Polynomial-C) from comment #31) > Alright, before the nagging escalates, here is what Chet Ramey, the bash > upstram maintainer/developer, told me via email regarding this problem: > > > If you have applied bash43-027, these bugs are local problems, so if you've > > already got the function name encoding patch in place you should be safe. Indeed, some of us are nagging. Please consider that the bugs presently under discussion belong to a class that might conceivably be locally exploitable, even if no such exploit is known of or has been demonstrated. If your stance is that you are not going to accept patches for these issues until Chet signs off on them then simply communicate the fact. Naturally, the security team calls the shots. That said, a precedent has already been set for rapid consumption of unofficial patches, as demonstrated by the handling of the shellshock related bug. Under the circumstances, you can't really blame people for wanting to see bash to be as safe as it can be in portage and opining so. Nor can you blame people for expressing concern - as some have - that a commit was made whose message implied that this bug was resolved when, in point of fact, it was not.
+*bash-4.3_p27-r1 (30 Sep 2014) +*bash-4.2_p50-r1 (30 Sep 2014) +*bash-4.1_p14-r1 (30 Sep 2014) + + 30 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> +bash-4.1_p14-r1.ebuild, + +bash-4.2_p50-r1.ebuild, -bash-4.3_p27.ebuild, +bash-4.3_p27-r1.ebuild, + +files/bash-redir-stack-overflow.patch: + Added an inofficial patch to finally fix CVE-2014-7186 and CVE-2014-7187 (bug + #523742). +
(In reply to Lars Wendler (Polynomial-C) from comment #33) > +*bash-4.3_p27-r1 (30 Sep 2014) > +*bash-4.2_p50-r1 (30 Sep 2014) > +*bash-4.1_p14-r1 (30 Sep 2014) > + > + 30 Sep 2014; Lars Wendler <polynomial-c@gentoo.org> > +bash-4.1_p14-r1.ebuild, > + +bash-4.2_p50-r1.ebuild, -bash-4.3_p27.ebuild, +bash-4.3_p27-r1.ebuild, > + +files/bash-redir-stack-overflow.patch: > + Added an inofficial patch to finally fix CVE-2014-7186 and CVE-2014-7187 > (bug > + #523742). > + Thanks, Lars. It is very much appreciated.
arm64/m68k/s390/sh stable
Arches, please test and mark stable the following bash versions: =app-shells/bash-4.1_p14-r1 =app-shells/bash-4.2_p50-r1 Target KEYWORDS are: alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
amd64 stable
I think we have the upstream fix now. http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-051
+ 01 Oct 2014; Agostino Sarubbo <ago@gentoo.org> bash-4.1_p14-r1.ebuild, + bash-4.2_p50-r1.ebuild: + Stable for alpha/arm/ia64/ppc/ppc64/sparc/sh/x86 wrt the security bug #523742 +
+ 01 Oct 2014; Sergey Popov <pinkbyte@gentoo.org> bash-4.2_p50-r1.ebuild: + s390 stable, wrt bug #523742
+*bash-4.3_p28 (01 Oct 2014) +*bash-4.2_p51 (01 Oct 2014) +*bash-4.1_p15 (01 Oct 2014) +*bash-4.0_p42 (01 Oct 2014) +*bash-3.2_p55 (01 Oct 2014) +*bash-3.1_p21 (01 Oct 2014) + + 01 Oct 2014; Lars Wendler <polynomial-c@gentoo.org> -bash-3.1_p19.ebuild, + +bash-3.1_p21.ebuild, -bash-3.2_p53.ebuild, +bash-3.2_p55.ebuild, + -bash-4.0_p40.ebuild, +bash-4.0_p42.ebuild, -bash-4.1_p13.ebuild, + -bash-4.1_p14-r1.ebuild, +bash-4.1_p15.ebuild, -bash-4.2_p49.ebuild, + -bash-4.2_p50-r1.ebuild, +bash-4.2_p51.ebuild, -bash-4.3_p27-r1.ebuild, + +bash-4.3_p28.ebuild, -files/bash-redir-stack-overflow.patch: + Finally the official patch to fix CVE-2014-7186 and CVE-2014-7187 is out (bug + #523742). Committed straight to stable where previous -r1 version was stable. + Arches, please test and mark stable the following bash versions: =app-shells/bash-3.1_p21 =app-shells/bash-3.2_p55 =app-shells/bash-4.0_p42 =app-shells/bash-4.1_p15 =app-shells/bash-4.2_p51 Target KEYWORDS are: alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
+ 02 Oct 2014; Agostino Sarubbo <ago@gentoo.org> bash-3.1_p21.ebuild, + bash-3.2_p55.ebuild, bash-4.0_p42.ebuild, bash-4.1_p15.ebuild, + bash-4.2_p51.ebuild: + Stable for alpha/amd64/arm/ia64/ppc/ppc64/sparc/sh/x86 wrt the security bug + #523742
arm64/m68k/s390 stable
I have removed old bash versions from portage. Thanks to all being involved.
Just an update on the further vulns, I don't know exactly how we should handle them: Michal Zalewski found two further parser issues (CVE-2014-6277, CVE-2014-6278). They are not exploitable once you have the prefix patch (bash42-050), however they are still (non-security-relevant) bugs. The very latest bash upstream patches (bash42-052, bash43-029) fix CVE-2014-6277, but not CVE-2014-6278. I expect another bash-upstream-patch to follow shortly. I think we should at least mention CVE-2014-6277 and CVE-2014-6278 in the GLSA and make clear that users are not vulnerable due to the prefixing. Further bash upstream-patches should receive bumps (obviously), however there's no immediate urgency in doing so.
(In reply to Hanno Boeck from comment #46) > Just an update on the further vulns, I don't know exactly how we should > handle them: Michal Zalewski found two further parser issues (CVE-2014-6277, > CVE-2014-6278). Bug 524256 exists for these. Lars has already committed 4.2_p52, taking care of -6277. As you say, these are not urgent. > > I think we should at least mention CVE-2014-6277 and CVE-2014-6278 in the > GLSA and make clear that users are not vulnerable due to the prefixing. Yes, that would be sensible.
CVE-2014-7187 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7187): Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the "word_lineno" issue. CVE-2014-7186 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7186): The redirection implementation in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via crafted use of here documents, aka the "redir_stack" issue.
This issue was resolved and addressed in GLSA 201410-01 at http://security.gentoo.org/glsa/glsa-201410-01.xml by GLSA coordinator Tobias Heinlein (keytoaster).