bug-bash-requ...@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-requ...@gnu.org > >You can reach the person managing the list at > bug-bash-ow...@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...@gmail.com) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sun, 28 Sep 2014 13:42:36 +0200 >From: Christian Weisgerber <na...@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.ga60...@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 na...@mips.inka.de > > > >------------------------------ > >Message: 2 >Date: Sun, 28 Sep 2014 07:46:48 -0400 >From: Nathan McGarvey <nathanmcgar...@gmail.com> >To: Eric Blake <ebl...@redhat.com> >Cc: bug-bash@gnu.org, chet.ra...@case.edu >Subject: Re: Bash-4.3 Official Patch 27 >Message-ID: > <CAAj_0uK-a3e00AkTm3hvS_EjpU3dShYL_7qVrGryxPg_rWr=z...@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" <ebl...@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 <na...@mips.inka.de> >To: bug-bash@gnu.org >Subject: Re: Patch file bash42-049 is broken >Message-ID: <20140928114855.gb60...@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 na...@mips.inka.de > > > >------------------------------ > >Message: 4 >Date: Sun, 28 Sep 2014 08:32:52 -0400 >From: Chet Ramey <chet.ra...@case.edu> >To: Deron Meranda <deron.mera...@gmail.com>, bug-bash@gnu.org >Cc: chet.ra...@case.edu >Subject: Re: Patch file bash42-049 is broken >Message-ID: <5427fff4.8010...@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 c...@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 <tav...@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.ra...@case.edu> >To: bug-bash@gnu.org >Cc: chet.ra...@case.edu >Subject: [UPDATE] Bash-4.2 Official Patch 49 >Message-ID: <140928124632.aa49746...@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 <tav...@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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/ > > > >------------------------------ > >Message: 6 >Date: Sun, 28 Sep 2014 01:32:25 -0700 (PDT) >From: TrevD <trevd1...@gmail.com> >To: bug-bash@gnu.org >Subject: Issues with restricted mode >Message-ID: <d411d2da-1056-4774-8072-1535bfd6f...@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 <mail3...@intekom.co.za> >To: bug-bash@gnu.org >Subject: ShellShok leak >Message-ID: > <774621461.54758857.1411896343296.javamail.r...@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...@gmail.com >To: bug-bash@gnu.org >Subject: Re: Bash-4.3 Official Patch 27 >Message-ID: <1d573c00-948d-4541-9e18-b34c6c030...@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 >*****************************************