Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 523742 (CVE-2014-7186) - <app-shells/bash-{3.1_p21, 3.2_p55, 4.0_p42, 4.1_p15, 4.2_p51}: Two out-of-bounds array accesses in the bash parser (CVE-2014-{7186,7187})
Summary: <app-shells/bash-{3.1_p21, 3.2_p55, 4.0_p42, 4.1_p15, 4.2_p51}: Two out-of-bo...
Status: RESOLVED FIXED
Alias: CVE-2014-7186
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal critical with 1 vote (vote)
Assignee: Gentoo Security
URL: http://seclists.org/oss-sec/2014/q3/712
Whiteboard: A1 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-25 22:39 UTC by Kerin Millar
Modified: 2014-10-04 22:14 UTC (History)
19 users (show)

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


Attachments
variables-affix.patch (variables-affix.patch,4.99 KB, patch)
2014-09-25 22:39 UTC, Kerin Millar
no flags Details | Diff
parser-oob.patch (parser-oob.patch,2.50 KB, patch)
2014-09-25 22:40 UTC, Kerin Millar
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kerin Millar 2014-09-25 22:39:27 UTC
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.
Comment 1 Kerin Millar 2014-09-25 22:40:09 UTC
Created attachment 385462 [details, diff]
parser-oob.patch
Comment 2 Yury German Gentoo Infrastructure gentoo-dev Security 2014-09-26 00:44:26 UTC
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
Comment 3 Lars Wendler (Polynomial-C) gentoo-dev 2014-09-26 04:38:34 UTC
Yeah, I'm also in favor of waiting for official upstream patches here.
Comment 4 Agostino Sarubbo gentoo-dev 2014-09-26 09:55:56 UTC
Is someone able to reproduce this bug with our bash versions?
Comment 5 Hanno Böck gentoo-dev 2014-09-26 09:57:44 UTC
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.
Comment 6 Kerin Millar 2014-09-26 13:42:29 UTC
(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.
Comment 7 Agostino Sarubbo gentoo-dev 2014-09-26 13:49:26 UTC
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
Comment 8 Kerin Millar 2014-09-26 14:13:35 UTC
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.
Comment 9 Kerin Millar 2014-09-26 14:15:10 UTC
Apologies, I mean Agostino.
Comment 10 Kerin Millar 2014-09-26 14:20:01 UTC
Here's an example. Fully reproducible on this box.

kerin@li356-58 ~ $ bash -c "true $(printf '<<EOF %.0s' {1..79})"
Segmentation fault
Comment 11 Kerin Millar 2014-09-26 18:00:01 UTC
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
Comment 12 Hanno Böck gentoo-dev 2014-09-27 18:41:55 UTC
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/
Comment 13 Kerin Millar 2014-09-27 21:17:42 UTC
(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.
Comment 14 Kerin Millar 2014-09-28 02:12:33 UTC
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.
Comment 15 Kerin Millar 2014-09-28 02:27:07 UTC
With variables-affix.patch, this works instead ...

# env 'BASH_FUNC_propagated_func()'='() { echo "propagated_func() called"; }' bash -c propagated_func
propagated_func() called
Comment 16 Kerin Millar 2014-09-28 02:41:45 UTC
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.
Comment 17 Hanno Böck gentoo-dev 2014-09-28 04:28:24 UTC
@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.
Comment 18 Kerin Millar 2014-09-28 04:45:16 UTC
(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.
Comment 19 David 2014-09-28 14:38:19 UTC
https://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-050

I think this is the upstream fix, right ?
Comment 20 Lars Wendler (Polynomial-C) gentoo-dev 2014-09-28 16:53:03 UTC
+*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.
Comment 21 Kerin Millar 2014-09-28 18:09:42 UTC
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.
Comment 22 Lars Wendler (Polynomial-C) gentoo-dev 2014-09-29 08:12:48 UTC
(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
Comment 23 Tobias Klausmann gentoo-dev 2014-09-29 09:01:35 UTC
(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).
Comment 24 Agostino Sarubbo gentoo-dev 2014-09-29 09:27:51 UTC
+  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.
Comment 25 Jeroen Roovers gentoo-dev 2014-09-29 09:29:58 UTC
Stable for HPPA.
Comment 26 fleg 2014-09-29 11:13:07 UTC
Still vilerable to CVE-2014-7186 (redir_stack bug).
Check with: https://github.com/hannob/bashcheck
Comment 27 Julian Ospald 2014-09-29 15:46:06 UTC
(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.
Comment 28 Jesse Adelman 2014-09-29 23:46:31 UTC
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.
Comment 29 Kerin Millar 2014-09-30 11:40:06 UTC
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.
Comment 30 Jie Li 2014-09-30 17:20:31 UTC
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.
Comment 31 Lars Wendler (Polynomial-C) gentoo-dev 2014-09-30 19:10:48 UTC
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.
Comment 32 Kerin Millar 2014-09-30 20:18:59 UTC
(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.
Comment 33 Lars Wendler (Polynomial-C) gentoo-dev 2014-09-30 20:34:59 UTC
+*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).
+
Comment 34 Kerin Millar 2014-09-30 20:37:22 UTC
(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.
Comment 35 Raúl Porcel (RETIRED) gentoo-dev 2014-10-01 07:57:40 UTC
arm64/m68k/s390/sh stable
Comment 36 Tobias Heinlein (RETIRED) gentoo-dev 2014-10-01 12:52:41 UTC
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
Comment 37 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2014-10-01 13:38:22 UTC
amd64 stable
Comment 38 David 2014-10-01 14:53:45 UTC
I think we have the upstream fix now.

http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-051
Comment 39 Agostino Sarubbo gentoo-dev 2014-10-01 16:07:28 UTC
+  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                                                                                                                                                                                               
+
Comment 40 Sergey Popov gentoo-dev Security 2014-10-01 16:41:51 UTC
+  01 Oct 2014; Sergey Popov <pinkbyte@gentoo.org> bash-4.2_p50-r1.ebuild:
+  s390 stable, wrt bug #523742
Comment 41 Lars Wendler (Polynomial-C) gentoo-dev 2014-10-01 20:48:14 UTC
+*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
Comment 42 Jeroen Roovers gentoo-dev 2014-10-02 08:20:43 UTC
Stable for HPPA.
Comment 43 Agostino Sarubbo gentoo-dev 2014-10-02 17:04:23 UTC
+  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
Comment 44 Raúl Porcel (RETIRED) gentoo-dev 2014-10-03 06:14:51 UTC
arm64/m68k/s390 stable
Comment 45 Lars Wendler (Polynomial-C) gentoo-dev 2014-10-03 09:16:54 UTC
I have removed old bash versions from portage. Thanks to all being involved.
Comment 46 Hanno Böck gentoo-dev 2014-10-03 11:03:00 UTC
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.
Comment 47 Kerin Millar 2014-10-03 11:12:09 UTC
(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.
Comment 48 GLSAMaker/CVETool Bot gentoo-dev 2014-10-04 18:04:05 UTC
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.
Comment 49 GLSAMaker/CVETool Bot gentoo-dev 2014-10-04 22:14:30 UTC
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).