Re: bug-bash Digest, Vol 142, Issue 53

[Thomas Mellman]

bug-bash-request@gnu.org wrote:

>Send bug-bash mailing list submissions to
>       bug-bash@gnu.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.gnu.org/mailman/listinfo/bug-bash
>or, via email, send a message with subject or body 'help' to
>       bug-bash-request@gnu.org
>
>You can reach the person managing the list at
>       bug-bash-owner@gnu.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of bug-bash digest..."
>
>
>Today's Topics:
>
>   1. Re: y.tab.c inclusion within the source tree
>      (Christian Weisgerber)
>   2. Re: Bash-4.3 Official Patch 27 (Nathan McGarvey)
>   3. Re: Patch file bash42-049 is broken (Christian Weisgerber)
>   4. Re: Patch file bash42-049 is broken (Chet Ramey)
>   5. [UPDATE] Bash-4.2 Official Patch 49 (Chet Ramey)
>   6. Issues with restricted mode (TrevD)
>   7. ShellShok leak (Franz Beck)
>   8. Re: Bash-4.3 Official Patch 27 (becker.rg@gmail.com)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sun, 28 Sep 2014 13:42:36 +0200
>From: Christian Weisgerber <naddy@mips.inka.de>
>To: Mark Goldfinch <g@g.org.nz>
>Cc: bug-bash@gnu.org
>Subject: Re: y.tab.c inclusion within the source tree
>Message-ID: <20140928114236.GA60499@lorvorc.mips.inka.de>
>Content-Type: text/plain; charset=us-ascii
>
>Mark Goldfinch:
>
>> Can someone clarify to me why y.tab.c is included within the bash source
>> tree if it is generated from parse.y?
>> 
>> If one looks in the FreeBSD ports tree, they're deliberately taking the
>> initiative to touch parse.y to ensure that y.tab.c is always rebuilt.
>
>They also have a dependency on the bison port, because parse.y does
>not build correctly with FreeBSD's yacc(1).  You end up with a bash
>that has broken $(...) parsing.  Same issue on OpenBSD, where the
>port doesn't touch parse.y because there is no need to.
>
>> If y.tab.c's timestamp ends up being newer than parse.y,
>
>Why would this happen?
>
>> a patch which (correctly) only patches parse.y,
>
>... will cause parse.y to have a newer timestamp.
>
>-- 
>Christian "naddy" Weisgerber                          naddy@mips.inka.de
>
>
>
>------------------------------
>
>Message: 2
>Date: Sun, 28 Sep 2014 07:46:48 -0400
>From: Nathan McGarvey <nathanmcgarvey@gmail.com>
>To: Eric Blake <eblake@redhat.com>
>Cc: bug-bash@gnu.org, chet.ramey@case.edu
>Subject: Re: Bash-4.3 Official Patch 27
>Message-ID:
>       <CAAj_0uK-a3e00AkTm3hvS_EjpU3dShYL_7qVrGryxPg_rWr=zA@mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Does anyone know if Red Hat intends on remerging with official bash? (This
>may be better directed at a seperate thread with them.)
>
>-Nathan
>On Sep 28, 2014 12:49 AM, "Eric Blake" <eblake@redhat.com> wrote:
>
>> On 09/27/2014 08:50 PM, Chet Ramey wrote:
>> >                            BASH PATCH REPORT
>> >                            =================
>>
>> >         /* Don't import function names that are invalid identifiers from
>> the
>> >            environment, though we still allow them to be defined as shell
>> >            variables. */
>> > !       if (absolute_program (tname) == 0 && (posixly_correct == 0 ||
>> legal_identifier (tname)))
>> > !         parse_and_execute (temp_string, tname,
>> SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
>>
>> This patch forbids importing function names containing '/' (yay!), and
>> we already established that bash has never been able to properly import
>> functions with names containing '='.  But I'm assuming there will need
>> to be a followup patch to actually reject the attempt to create such
>> function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
>> issue an error message instead of printing "oops"), so that we do not
>> have the confusing situation of being unable to pass all permitted
>> function names through an export/import cycle.
>>
>> By the way, thanks for this patch - it plugs CVE-2014-7186,
>> CVE-2014-7187, and CVE-2014-6277 (and probably other parser crashes)
>> from remote exploits down to merely annoying local bugs that can no
>> longer be abused for privilege escalation.  In other words, it is THIS
>> patch that plugs the Shell Shock issue, even though there are still more
>> patches needed to plug all of the parser holes that Shell Shock has
>> uncovered.
>>
>> --
>> Eric Blake   eblake redhat com    +1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
>>
>>
>
>
>------------------------------
>
>Message: 3
>Date: Sun, 28 Sep 2014 13:48:55 +0200
>From: Christian Weisgerber <naddy@mips.inka.de>
>To: bug-bash@gnu.org
>Subject: Re: Patch file bash42-049 is broken
>Message-ID: <20140928114855.GB60499@lorvorc.mips.inka.de>
>Content-Type: text/plain; charset=us-ascii
>
>Deron Meranda:
>
>> I was wondering if anybody was going to address the problem with 4.2 patch
>> 49 ?
>> 
>> It is still corrupted on the FTP server.  There are a few lines that appear
>> to have been deleted out of the middle of the patch file.
>
>Indeed.
>
>> Not only is there a critical line of code missing, but the the 'patch'
>> command will also fail when used with the --fuzz=0 option -- which is
>> something that rpmbuild (Fedora, etc) uses.
>
>That's GNU patch.  OpenBSD's patch just fails with it.
>
>-- 
>Christian "naddy" Weisgerber                          naddy@mips.inka.de
>
>
>
>------------------------------
>
>Message: 4
>Date: Sun, 28 Sep 2014 08:32:52 -0400
>From: Chet Ramey <chet.ramey@case.edu>
>To: Deron Meranda <deron.meranda@gmail.com>, bug-bash@gnu.org
>Cc: chet.ramey@case.edu
>Subject: Re: Patch file bash42-049 is broken
>Message-ID: <5427FFF4.8010508@case.edu>
>Content-Type: text/plain; charset="iso-8859-1"
>
>On 9/28/14, 12:51 AM, Deron Meranda wrote:
>> I was wondering if anybody was going to address the problem with 4.2 patch
>> 49 ?
>
>I've attached a corrected version and I will update the FTP sites today.
>
>> Not only is there a critical line of code missing, but the the 'patch'
>> command will also fail when used with the --fuzz=0 option -- which is
>> something that rpmbuild (Fedora, etc) uses.
>
>There are no missing lines of code -- the entire patch is one line to
>parse.y, which fixes the underlying problem CVE-2014-7169 exploits.
>
>Chet
>
>-- 
>``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
>Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
>-------------- next part --------------
>                            BASH PATCH REPORT
>                            =================
>
>Bash-Release:  4.2
>Patch-ID:      bash42-049
>
>Bug-Reported-by:       Tavis Ormandy <taviso@cmpxchg8b.com>
>Bug-Reference-ID:
>Bug-Reference-URL:     http://twitter.com/taviso/statuses/514887394294652929
>
>Bug-Description:
>
>Under certain circumstances, bash can incorrectly save a lookahead character 
>and
>return it on a subsequent call, even when reading a new line.
>
>Patch (apply with `patch -p0'):
>
>*** ../bash-4.2.48/parse.y     2012-12-31 11:52:57.000000000 -0500
>--- parse.y    2014-09-25 16:12:19.000000000 -0400
>***************
>*** 2851,2854 ****
>--- 2851,2856 ----
>    word_desc_to_read = (WORD_DESC *)NULL;
>  
>+   eol_ungetc_lookahead = 0;
>+ 
>    current_token = '\n';              /* XXX */
>    last_read_token = '\n';
>*** ../bash-4.2-patched/patchlevel.h   Sat Jun 12 20:14:48 2010
>--- patchlevel.h       Thu Feb 24 21:41:34 2011
>***************
>*** 26,30 ****
>     looks for to find the patch level (for the sccs version string). */
>  
>! #define PATCHLEVEL 48
>  
>  #endif /* _PATCHLEVEL_H_ */
>--- 26,30 ----
>     looks for to find the patch level (for the sccs version string). */
>  
>! #define PATCHLEVEL 49
>  
>  #endif /* _PATCHLEVEL_H_ */
>
>------------------------------
>
>Message: 5
>Date: Sun, 28 Sep 2014 08:46:32 -0400
>From: Chet Ramey <chet.ramey@case.edu>
>To: bug-bash@gnu.org
>Cc: chet.ramey@case.edu
>Subject: [UPDATE] Bash-4.2 Official Patch 49
>Message-ID: <140928124632.AA49746.SM@caleb.ins.cwru.edu>
>Content-Type: text/plain; charset=us-ascii
>
>                            BASH PATCH REPORT
>                            =================
>
>Bash-Release:  4.2
>Patch-ID:      bash42-049
>
>Bug-Reported-by:       Tavis Ormandy <taviso@cmpxchg8b.com>
>Bug-Reference-ID:
>Bug-Reference-URL:     http://twitter.com/taviso/statuses/514887394294652929
>
>Bug-Description:
>
>Under certain circumstances, bash can incorrectly save a lookahead character 
>and
>return it on a subsequent call, even when reading a new line.
>
>Patch (apply with `patch -p0'):
>
>*** ../bash-4.2.48/parse.y     2012-12-31 11:52:57.000000000 -0500
>--- parse.y    2014-09-25 16:12:19.000000000 -0400
>***************
>*** 2851,2854 ****
>--- 2851,2856 ----
>    word_desc_to_read = (WORD_DESC *)NULL;
>  
>+   eol_ungetc_lookahead = 0;
>+ 
>    current_token = '\n';              /* XXX */
>    last_read_token = '\n';
>*** ../bash-4.2-patched/patchlevel.h   Sat Jun 12 20:14:48 2010
>--- patchlevel.h       Thu Feb 24 21:41:34 2011
>***************
>*** 26,30 ****
>     looks for to find the patch level (for the sccs version string). */
>  
>! #define PATCHLEVEL 48
>  
>  #endif /* _PATCHLEVEL_H_ */
>--- 26,30 ----
>     looks for to find the patch level (for the sccs version string). */
>  
>! #define PATCHLEVEL 49
>  
>  #endif /* _PATCHLEVEL_H_ */
>
>-- 
>``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
>Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
>
>
>
>------------------------------
>
>Message: 6
>Date: Sun, 28 Sep 2014 01:32:25 -0700 (PDT)
>From: TrevD <trevd1234@gmail.com>
>To: bug-bash@gnu.org
>Subject: Issues with restricted mode
>Message-ID: <d411d2da-1056-4774-8072-1535bfd6fdbf@googlegroups.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>Hi
>
>There a number of issue in restricted mode. What's the best method for 
>disclosure.
>
>
>------------------------------
>
>Message: 7
>Date: Sun, 28 Sep 2014 11:25:43 +0200 (SAST)
>From: Franz Beck <mail3782@intekom.co.za>
>To: bug-bash@gnu.org
>Subject: ShellShok leak
>Message-ID:
>       <774621461.54758857.1411896343296.JavaMail.root@intekom.co.za>
>Content-Type: text/plain; charset=utf-8
>
>Please refer to below Focus Article:
>http://www.focus.de/digital/schlimmer-als-heartbleed-sicherheitsluecke-bedroht-linux-unix-und-mac-os-x_id_4160658.html
>
>Thanks for your attention!
>
>Franz
>Johannesburg
>
>
>
>------------------------------
>
>Message: 8
>Date: Sun, 28 Sep 2014 08:38:24 -0700 (PDT)
>From: becker.rg@gmail.com
>To: bug-bash@gnu.org
>Subject: Re: Bash-4.3 Official Patch 27
>Message-ID: <1d573c00-948d-4541-9e18-b34c6c030616@googlegroups.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Sunday, September 28, 2014 3:50:07 AM UTC+1, Chet Ramey wrote:
>> BASH PATCH REPORT
>> 
>..........
>> -- 
>> 
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>> 
>>               ``Ars longa, vita brevis'' - Hippocrates
>> 
>> Chet Ramey, ITS, CWRU    c........
>
>If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch then 
>I have a patch against the at(1) source which converts exported functions into 
>something that sh can parse and allows exported functions to be used in the 
>environment that calls at.
>
>Looking at this list it's not clear to me if the dust has settled on the 
>shellshock fixes. Should I wait before sharing my patch or not?
>
>Also is there anyone here who knows where such a patch should be sent?
>
>
>------------------------------
>
>_______________________________________________
>bug-bash mailing list
>bug-bash@gnu.org
>https://lists.gnu.org/mailman/listinfo/bug-bash
>
>
>End of bug-bash Digest, Vol 142, Issue 53
>*****************************************