Input line wrapping broken in 4.3.27 if built using included libtermcap
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux renegade 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 27 Release Status: release Description: This is a bug affecting the latest of the shellshock patches at the time of writing, 4.3.27. If bash is configured and built on a system with no libtermcap, it attempts to build statically linking its own one. In this case, the resulting bash that is built does not correctly wrap long input lines. Repeat-By: ./configure while no libtermcap is available, or make the following changes to the configured makefile: < LDFLAGS = $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS) $(CFLAGS) --- > LDFLAGS = -L./lib/termcap $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS) $(CFLAGS) 311c311 < TERMCAP_LIB = -ltermcap --- > TERMCAP_LIB = ./lib/termcap/libtermcap.a 314c314 < TERMCAP_DEP = --- > TERMCAP_DEP = ./lib/termcap/libtermcap.a Fix: Immediate workaround is to install libtermcap. The bug appears to have been introduced between patches 4.3.25 and 4.3.27.
Re: y.tab.c inclusion within the source tree
On 9/28/14, 4:33 PM, Mark Goldfinch wrote: > On 29 September 2014 00:42, Christian Weisgerber wrote: > >> 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. >> > > For these platforms, if anyone is using the patches directly from the GNU > repository, if they're *not* running 4.3 they could well be still > vulnerable if they're reliant upon the supplied y.tab.c: > > bash205b-009: y.tab.c unpatched > bash30-018: y.tab.c unpatched > bash31-019: y.tab.c unpatched > bash40-040: y.tab.c unpatched > bash41-013: y.tab.c unpatched > bash42-049: y.tab.c unpatched > bash43-026: y.tab.c patched OK. The reason for this is because in bash-4.3, I changed the patch process to include patches for y.tab.c if parse.y was changed. This is to reduce -- but not completely eliminate -- the dependency on bison. Previous versions didn't include changes to y.tab.c in patches to parse.y, so you can't assume that the y.tab.c in the source tree is up to date, and patching it would have had unintended side effects. If you're wondering how this could be, consider an environment that separates source and build trees (configure makes this very easy). In this case, y.tab.c will be created in the build tree after parse.y is updated, but the original y.tab.c in the source tree, while it was valid before the patch, is now out of date. > Assuming the files have been edited in the correct order. It's hard to imagine a situation where parse.y gets patched, y.tab.c doesn't, and y.tab.c still ends up newer than parse.y. A system with clock problems that bad probably has bigger problems, too. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: y.tab.c inclusion within the source tree
On 9/28/14, 4:01 AM, Mark Goldfinch wrote: > Greetings, > > On 28 Sep 2014 19:41, "John E. Malmberg" wrote: >> >> On 9/27/2014 6:49 PM, Mark Goldfinch wrote: >>> 1) Remove y.tab.c from the original tarball, and ensure the clean method >>> within Makefile removes it >> >> The VMS build procedure currently needs the y.tab.c file, as the tools to > build it on VMS are not current. > > OK - thanks for pointing this out. > > Two questions spring to mind: > > 1) ./configure must learn whether current yacc/bison is present - when it > does surely it can take action to ensure y.tab.c is always going to be > produced from parse.y - does this seem reasonable? It can do the first. How could it possibly do the second without breaking the way makefiles are supposed to work? The way to do this is to use make and timestamps. You can't assume that configure is run after running patch. > 2) Are there other supported build platforms for bash which fall into the > same category as VMS? Is it unreasonable to require an officially > supported build platform to have the required build tools? I want bash to have few external dependencies. I can do part of this by shipping y.tab.c and y.tab.h as part of the distribution. > There's been discussion about dropping POSIX mode support in a future > version of bash No, there hasn't. > I raise this as I have met with surprise problems associated with y.tab.c's > timestamp being newer than parse.y but only having parse.y patched. And when parse.y gets patched, its timestamp gets updated, making it newer than y.tab.c. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: REGRESSION: shellshock patch rejects valid function names
On 9/27/14, 10:03 PM, Eric Blake wrote: >> Yes, it's an application requirement. Regardless, all the versions of bash >> we're talking about here reject non-identifiers. > > I'm still trying to find that line in the actual POSIX spec. "The function is named fname; the application shall ensure that it is a name (see XBD Name) and that it is not the name of a special built-in utility." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05 > -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Issues with exported functions
On 9/28/14, 12:31 PM, Ángel González wrote: > There's also the middleground of not parsing the environment variables > before they are going to be used. That avoids the issues caused by > parsing what is not needed *and* doesn't break backwards compatibility. > See the patch I sent a couple days ago. That's a reasonably elegant extension, but it doesn't really solve the problem any better than fixing the underlying parser problem. A user who can figure out how to pass a function with the appropriate name encoding, which at this point nobody has figured out to do remotely, can more than likely arrange for that function to be called, at which point it will be parsed and any underlying parser bug exposed. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.3 Official Patch 27
On 9/28/14, 12:10 PM, becker...@gmail.com wrote: > On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: > .. >> 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. >> > ... > > Jon Seymour asked me if my at patch would fix the following vulnerablity > (presumably in at(1)) > > echo pwd | env "/tmp/exploit=me" at tomorrow > > which I presume relies on acceptance of /tmp/exploit=me as a possible > command. I'm not sure it does since the current at code writes the variable > name out unconditionally (ie no inspection of characters etc etc). I could > probably raise an error for bad variable names, but I'm not sure I understand > what characters are now illegal or what the lexical definition of bash/sh > variable names is now. So I would appreciate advice on that. Variable names have the same grammar they always have: letters, digits, underscores, may not start with a digit. It's best to just ignore and pass along environment strings that you don't recognize. That's one of the goals of the changes in patch 27: to encode exported shell function names in a way that won't collide with valid shell variable names and assignment statements. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.3 Official Patch 27
� wrote: The change only affects environment variables **loaded as exported functions**. Bash won't forbid you from using / inside the name of an environment variables. The below doesn't demonstrate bash doing anything with the variable you declared. You declare an ENV var with 'env' (not part of bash), then you start a new shell and use env to see that the original value is still there. It should be. You are not demonstrating any interaction with BASH. You can easily confirm with: env -i 'foo/bar=baz' bash -c env Best regards Please fix your 'From' line. It shows up as garbage. Maybe it is your upstream ISP mailer.hiddenmail.het?
Re: Bash-4.3 Official Patch 27
On 9/28/14, 11:38 AM, becker...@gmail.com wrote: > 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. This looks like a problem with `at' assuming that everything in the environment is a valid shell assignment statement (or equivalent). Since the environment can include arbitrary strings, that's not a safe assumption. Bash, for instance, ignores and passes environment strings that it doesn't recognize as valid assignment statements. > Also is there anyone here who knows where such a patch should be sent? I'd send it to your vendor. If appropriate they can send it upstream. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.3 Official Patch 27
On 9/28/14, 12:48 AM, Eric Blake wrote:
> 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.
I have not decided whether to reject the creation of such functions,
since bash never has, or to reject the attempt to export them.
That's a discussion that can be deferred.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ShellShok leak
On 9/28/14, 5:25 AM, Franz Beck wrote: > 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 Sorry, I'm mono-lingual. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: y.tab.c inclusion within the source tree
On 29 September 2014 00:42, Christian Weisgerber wrote: > 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. > For these platforms, if anyone is using the patches directly from the GNU repository, if they're *not* running 4.3 they could well be still vulnerable if they're reliant upon the supplied y.tab.c: bash205b-009: y.tab.c unpatched bash30-018: y.tab.c unpatched bash31-019: y.tab.c unpatched bash40-040: y.tab.c unpatched bash41-013: y.tab.c unpatched bash42-049: y.tab.c unpatched bash43-026: y.tab.c patched Granted the subsequent patch should take care of things too. > a patch which (correctly) only patches parse.y, > > ... will cause parse.y to have a newer timestamp. > Assuming the files have been edited in the correct order. While I understand the reasons for including a generated copy, this only add yet another maintenance burden - surely for platforms where the required bison is available, the build-chain should take steps to ensure y.tab.c is actually generated. For everyone else surely it should be their responsibility to have the required tools available at build time? Thanks, Mark.
Re: Bash-4.3 Official Patch 27
The change only affects environment variables **loaded as exported functions**. Bash won't forbid you from using / inside the name of an environment variables. You can easily confirm with: > env -i 'foo/bar=baz' bash -c env Best regards
Re: Issues with restricted mode
On 9/28/14, 4:32 AM, TrevD wrote: > Hi > > There a number of issue in restricted mode. What's the best method for > disclosure. Restricted mode (set -r) has a number of well-known weaknesses and survives only as a historical artifact. It's not a serious security mechanism. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Issues with exported functions
David A. Wheeler wrote: > 2. Import environment variables *ONLY* when they are requested; do *NOT* > import them by default. Christos Zoulas has proposed this. This *IS* a real > backwards-incompatible change. But most users do *NOT* use this > functionality, and increasingly downstream systems are *already* switching to > this mode. E.G., FreeBSD has already switched to this; function imports > require --import-functions or enabling the IMPORTFUNCTIONS option. E.G., > see: https://svnweb.freebsd.org/ports?view=revision&revision=369341 > This change eliminates the entire class of problems. It's still good to do > #1, even with #2, because if someone DOES perform an import, it reduces the > probability of accidentally importing the wrong thing. People are ALREADY > making this change, whether upstream does or not. > There's also the middleground of not parsing the environment variables before they are going to be used. That avoids the issues caused by parsing what is not needed *and* doesn't break backwards compatibility. See the patch I sent a couple days ago. > John Haxby recently posted that "A friend of mine said this could be a > vulnerability gift that keeps on giving." > (http://seclists.org/oss-sec/2014/q3/748). Bash will be a continuous rich > source of system vulnerabilities until it STOPS automatically parsing normal > environment variables; all other shells just pass them through! I've turned > off several websites I control because I have *no* confidence that the > current official bash patches actually stop anyone, and I am deliberately > *not* buying products online today for the same reason. I suspect others > have done the same. I think it's important that bash change its semantics so > that it "obviously has absolutely no problems of this kind". That's exactly what my patch does, although it wouldn't be transparent if used inside bash (eg. echo $FUNC), as opposed of usage by its children (wouldn't be hard to change, though).
Re: Bash-4.3 Official Patch 27
| correction: variable called "/tmp/exploit=me" => a variable called "/tmp/exploit" with a value "me" On Mon, Sep 29, 2014 at 2:26 AM, Jon Seymour wrote: > To clarify, I am not sure that the presence of a variable called > "/tmp/exploit=me" represents a huge vuilnerability for at(1) since > anyone who can arrange for this to happen can probably mutate the > user's environment in anyway they choose, but I did want to point out > that atrun will attempt to execute '/tmp/exploit=me' as a /bin/sh > command and should there be a executable file at that path, then an > unexpected execution may result. > > I note that my OSX environment currently contains this variable > injected by Chrome: > > COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket > > and attempts to invoke 'at' result in unexpected attempts to execute a > file called: > > COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket > > when 'atrun' runs. Of course, to exploit this, the attacker would have > to be able to create a file of that name on the filesystem and enable > 'atrun' (which is apparently disabled by default on OSX). > > > > On Mon, Sep 29, 2014 at 2:10 AM, wrote: >> On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: >> .. >>> 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. >>> >> ... >> >> Jon Seymour asked me if my at patch would fix the following vulnerablity >> (presumably in at(1)) >> >> echo pwd | env "/tmp/exploit=me" at tomorrow >> >> which I presume relies on acceptance of /tmp/exploit=me as a possible >> command. I'm not sure it does since the current at code writes the variable >> name out unconditionally (ie no inspection of characters etc etc). I could >> probably raise an error for bad variable names, but I'm not sure I >> understand what characters are now illegal or what the lexical definition of >> bash/sh variable names is now. So I would appreciate advice on that.
Re: Bash-4.3 Official Patch 27
To clarify, I am not sure that the presence of a variable called "/tmp/exploit=me" represents a huge vuilnerability for at(1) since anyone who can arrange for this to happen can probably mutate the user's environment in anyway they choose, but I did want to point out that atrun will attempt to execute '/tmp/exploit=me' as a /bin/sh command and should there be a executable file at that path, then an unexpected execution may result. I note that my OSX environment currently contains this variable injected by Chrome: COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket and attempts to invoke 'at' result in unexpected attempts to execute a file called: COM_GOOGLE_CHROME_FRAMEWORK_SERVICE_PROCESS/USERS/JONSEYMOUR/LIBRARY/APPLICATION_SUPPORT/GOOGLE/CHROME_SOCKET=/tmp/launch-5VzA1C/ServiceProcessSocket when 'atrun' runs. Of course, to exploit this, the attacker would have to be able to create a file of that name on the filesystem and enable 'atrun' (which is apparently disabled by default on OSX). On Mon, Sep 29, 2014 at 2:10 AM, wrote: > On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: > .. >> 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. >> > ... > > Jon Seymour asked me if my at patch would fix the following vulnerablity > (presumably in at(1)) > > echo pwd | env "/tmp/exploit=me" at tomorrow > > which I presume relies on acceptance of /tmp/exploit=me as a possible > command. I'm not sure it does since the current at code writes the variable > name out unconditionally (ie no inspection of characters etc etc). I could > probably raise an error for bad variable names, but I'm not sure I understand > what characters are now illegal or what the lexical definition of bash/sh > variable names is now. So I would appreciate advice on that.
Re: Bash-4.3 Official Patch 27
On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote: .. > 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. > ... Jon Seymour asked me if my at patch would fix the following vulnerablity (presumably in at(1)) echo pwd | env "/tmp/exploit=me" at tomorrow which I presume relies on acceptance of /tmp/exploit=me as a possible command. I'm not sure it does since the current at code writes the variable name out unconditionally (ie no inspection of characters etc etc). I could probably raise an error for bad variable names, but I'm not sure I understand what characters are now illegal or what the lexical definition of bash/sh variable names is now. So I would appreciate advice on that.
Re: Bash-4.3 Official Patch 27
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, CWRUc 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?
ShellShok leak
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
Issues with restricted mode
Hi There a number of issue in restricted mode. What's the best method for disclosure.
[UPDATE] Bash-4.2 Official Patch 49
BASH PATCH REPORT = Bash-Release: 4.2 Patch-ID: bash42-049 Bug-Reported-by:Tavis Ormandy 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.0 -0500 --- parse.y 2014-09-25 16:12:19.0 -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.hSat Jun 12 20:14:48 2010 --- patchlevel.hThu 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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Patch file bash42-049 is broken
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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ BASH PATCH REPORT = Bash-Release: 4.2 Patch-ID: bash42-049 Bug-Reported-by:Tavis Ormandy 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.0 -0500 --- parse.y 2014-09-25 16:12:19.0 -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.hSat Jun 12 20:14:48 2010 --- patchlevel.hThu 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_ */
Re: Patch file bash42-049 is broken
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
Re: Bash-4.3 Official Patch 27
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" 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
>
>
Re: y.tab.c inclusion within the source tree
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
Re: y.tab.c inclusion within the source tree
Greetings, On 28 Sep 2014 19:41, "John E. Malmberg" wrote: > > On 9/27/2014 6:49 PM, Mark Goldfinch wrote: >> 1) Remove y.tab.c from the original tarball, and ensure the clean method >> within Makefile removes it > > The VMS build procedure currently needs the y.tab.c file, as the tools to build it on VMS are not current. OK - thanks for pointing this out. Two questions spring to mind: 1) ./configure must learn whether current yacc/bison is present - when it does surely it can take action to ensure y.tab.c is always going to be produced from parse.y - does this seem reasonable? 2) Are there other supported build platforms for bash which fall into the same category as VMS? Is it unreasonable to require an officially supported build platform to have the required build tools? There's been discussion about dropping POSIX mode support in a future version of bash - perhaps reviewing what platforms are officially supported is a worthwhile discussion. I raise this as I have met with surprise problems associated with y.tab.c's timestamp being newer than parse.y but only having parse.y patched. Thanks, Mark.
