Re: Issues with exported functions

2014-09-25 6:23 GMT+02:00 Linda Walsh : > > Maybe exporting fun? > > export fun='() { :;}' >> bash -c 'declare -pf fun' >> > bash: line 0: declare: fun: not found > ... > I've never seen functions created with an assignment. Is this a > new syntax in 4.3? > > (still in 4.2.43 here)... Bash ha

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 9:35 AM, Chet Ramey wrote: > On 9/24/14, 3:44 PM, lolilolicon wrote: > >> Personally, I have never needed this feature. I would vote for its >> removal: It's very surprising, creates bugs, and is not very useful. > > There are more things in heaven and earth that are dreamt

Re: Issues with exported functions

On Wed, 24 Sep 2014 21:35:19 -0400, Chet Ramey wrote: > On 9/24/14, 3:44 PM, lolilolicon wrote: > > > Personally, I have never needed this feature. I would vote for its > > removal: It's very surprising, creates bugs, and is not very useful. > > There are more things in heaven and earth that ar

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 11:06 AM, lolilolicon wrote: > On Thu, Sep 25, 2014 at 9:35 AM, Chet Ramey wrote: > > On 9/24/14, 3:44 PM, lolilolicon wrote: > > > >> Personally, I have never needed this feature. I would vote for its > >> removal: It's very surprising, creates bugs, and is not very usef

Re: Issues with exported functions

2014-09-25 10:43 GMT+02:00 Davide Brini : > I'm not arguing about anything, I just have a question. I understand that > with the current method used to export functions, it is not possible to > export a variable to a child whose value begins exactly with the characters > in question. A quick test

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote: > lolilolicon wrote: >> >> I don't expect more than a dozen who rely on this... but bash >> programmers can be quite the perverts, so... >> > > Personally I find those who don't read the man page, and then claim that > documented > behavior is a

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon wrote: > On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote: > > lolilolicon wrote: > >> > >> I don't expect more than a dozen who rely on this... but bash > >> programmers can be quite the perverts, so... > >> > > > > Personally I find those who don

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 5:51 PM, Pierre Gaston wrote: > > > On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon wrote: >> >> On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote: >> > lolilolicon wrote: >> >> >> >> I don't expect more than a dozen who rely on this... but bash >> >> programmers can be qu

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 1:04 PM, lolilolicon wrote: > On Thu, Sep 25, 2014 at 5:51 PM, Pierre Gaston > wrote: > > > > > > On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon > wrote: > >> > >> On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote: > >> > lolilolicon wrote: > >> >> > >> >> I don't expec

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 6:09 PM, Pierre Gaston wrote: >> In any event, this is but irrelevant to the discussion. Do not seize the >> red herring. > > > It is fully relevant when you use a sexist stereotype as an argument. No, I didn't use a sexist stereotype "as an argument". Remove that sentence

Re: Issues with exported functions

Hello, As the interface is not specified, would it make sense to: * add a prefix (use BASH_FUNCTION_foo instead of foo for exported function foo); * still expand the variable if it matches the 'exported function' pattern. The first point would reduce the probability of a clash with a us

Re: Issues with exported functions

Hello, As the interface is not specified, would it make sense to: * add a prefix (use BASH_FUNCTION_foo instead of foo for exported function foo); * still expand the variable if it matches the 'exported function' pattern. The first point would reduce the probability of a clash with a us

Re: Issues with exported functions

On 9/25/14, 4:43 AM, Davide Brini wrote: >> Function export is documented. The exact mechanism need not be. > > I'm not arguing about anything, I just have a question. I understand that > with the current method used to export functions, it is not possible to > export a variable to a child whose

Re: Issues with exported functions

On 9/25/14, 6:12 AM, lolilolicon wrote: > On Thu, Sep 25, 2014 at 6:09 PM, Pierre Gaston > wrote: >>> In any event, this is but irrelevant to the discussion. Do not seize the >>> red herring. >> >> >> It is fully relevant when you use a sexist stereotype as an argument. > > No, I didn't use a se

Re: Issues with exported functions

On 9/25/14, 4:52 AM, Gabriel Corona wrote: > Hello, > > As the interface is not specified, would it make sense to: > > * add a prefix (use BASH_FUNCTION_foo instead of foo for exported >function foo); > > * still expand the variable if it matches the 'exported function' >pattern. Yes,

Re: Bash-4.3 Official Patch 25

Hi, This patch does not seem to work on HP-UX: $ ./bash --version GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software; you are free to change

Re: Bash-4.3 Official Patch 25

On Thu, Sep 25, 2014 at 06:02:11AM -0700, gnu.bash.bug wrote: > Hi, > > This patch does not seem to work on HP-UX: Worked for me on 10.20. > > $ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello' > vulnerable > hello imadev:~$ uname -a HP-UX imadev B.10.20 A 9000/785 2008897791 tw

Re: Bash-4.3 Official Patch 25

On 9/25/14, 9:02 AM, gnu.bash.bug wrote: > Hi, > > This patch does not seem to work on HP-UX: > > $ ./bash --version > GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31) > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later

Re: Bash-4.3 Official Patch 25

Ah great, thanks for that...though since there's still the bug in p025 (see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 ) I'll keep spinning my wheels and watching the git branches until p026 rolls out. ta, Mark On Thu, Sep 25, 2014 at 3:55 PM, Chris F.A. Johnson wrote: > On Wed

Re: Bash-4.3 Official Patch 25

On 9/24/14, 6:50 PM, Wesley Hirsch wrote: > Also, you can embed arguments, allowing for arbitrary execution: > > $ env -i X='() { (a)=>\' bash -c 'echo curl -s https://bugzilla.redhat.com/'; > head echo > bash: X: line 1: syntax error near unexpected token `=' > bash: X: line 1: `' This is an un

Re: Bash-4.3 Official Patch 25

>Are you absolutely sure that the "bash" your command is invoking is >the patched one? You are right! I had like 4 other bash versions in my PATH So case closed... ;) Thanks! Michael

Re: Bash-4.3 Official Patch 25

Good day Chet, bash-list - I just checked out the latest git head, applied the bash43-025 patch, and built $ ./bash --version GNU bash, version 4.3.25(3)-release (x86_64-unknown-linux-gnu) ... which PASSED its 'make check' test suite, both under Ubuntu 14.04.1 LTS and under RHEL-6.5+ , on an x

Re: Bash-4.3 Official Patch 25

On Thu, Sep 25, 2014 at 02:50:03PM +0100, Jason Vas Dias wrote: > But now there is an issue - bash seems to lose its idea of stdout / stderr > being > a terminal within read loops, as illustrated by this test script (/tmp/t.sh): > > > #!/bin/bash > tty > echo $'1\n2' > test.list; > while read l

Re: Bash-4.3 Official Patch 25

Jason Vas Dias writes: > > #!/bin/bash > tty > echo $'1\n2' > test.list; > while read line; do > tty; > done < test.list > > > Its output illustrates the problem: > > > $ ./bash /tmp/t.sh > /dev/pts/6 > not a tty > not a tty > tty uses stdin, so this is the expected output. Why do you

Re: Bash-4.3 Official Patch 25

Oops, sorry, this issue is nothing to do with the bash43-025 patch - I just verified that the same issue occurs with bash 4.1.2(1) . The issue was that a script that does an 'stty' command was failing when run in a 'while read ... ' loop. It wasn't using 'stty -F', so was trying to stty on stdin,

Re: Issues with exported functions

On Thu, Sep 25, 2014 at 9:00 PM, Chet Ramey wrote: > Even if you use it as a rhetorical device, it distracts from (and detracts > from) your argument. It doesn't improve the quality of the discussion, so > it's best not to use it. Agreed. People can take light-hearted side remarks too seriously.

Re: Issues with exported functions

On Thursday, September 25, 2014 09:03:03 AM Chet Ramey wrote: > On 9/25/14, 4:52 AM, Gabriel Corona wrote: > > Hello, > > > > As the interface is not specified, would it make sense to: > > > > * add a prefix (use BASH_FUNCTION_foo instead of foo for exported > >function foo); > > > > * sti

Re: Issues with exported functions

On 9/25/14, 10:25 AM, Dan Douglas wrote: > Have you considered the FPATH mechanism? Exploiting it requires being able to > create files and set FPATH accordingly. I've had some success with the > function loader code in examples/functions/autoload.*. I believe it serves > mostly the same purpos

Re: Issues with exported functions

On Thursday, September 25, 2014 10:29:16 AM Chet Ramey wrote: > On 9/25/14, 10:25 AM, Dan Douglas wrote: > > > Have you considered the FPATH mechanism? Exploiting it requires being able to > > create files and set FPATH accordingly. I've had some success with the > > function loader code in exa

Re: Issues with exported functions

On 09/25/2014 07:03 AM, Chet Ramey wrote: > On 9/25/14, 4:52 AM, Gabriel Corona wrote: >> Hello, >> >> As the interface is not specified, would it make sense to: >> >> * add a prefix (use BASH_FUNCTION_foo instead of foo for exported >>function foo); I'd much rather prefer the use of an inval

Re: Bash security issue

On 09/25/2014 11:21 AM, Nick Bowler wrote: > On 2014-09-25 08:55 -0600, Eric Blake wrote: >> On 09/25/2014 07:51 AM, Bob Friesenhahn wrote: >>> It may be that some users of 'autoconf' will be at risk due to the dire >>> bash security bug described at >>> "http://www.theregister.co.uk/2014/09/24/bas

Re: Issues with exported functions

Steve Simmons wrote: > ..bash_once defines SET_ONCE and loads literally hundreds of environment > variables and exports many shell functions that would otherwise have to be > defined in .bashrc and processed on every freaking run. .bash_once is about > 50 times larger than .bashrc and .bash_logi

Re: Issues with exported functions

On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote: [...] > On the other hand, this approach would be much more interesting if bash > delayed parsing of exported functions until they are used (ie. check This is what function autoload is for in zsh. It's indeed a better approach. It was also su

Re: Issues with exported functions

lolilolicon wrote: On Thu, Sep 25, 2014 at 9:00 PM, Chet Ramey wrote: > Even if you use it as a rhetorical device, it distracts from (and > detracts from) your argument. It doesn't improve the quality of the > discussion, so it's best not to use it. Agreed. People can take light-hearted side

Re: Bash security issue

Eric Blake wrote: And _that's_ what I want changed, by proposing that bash use 'f()=...' rather than 'f=() {...' as the magic it uses for exporting functions from parent to child. --- That could still be put in the environment (though not as easily w/o special code). Not that it is any mor

Re: Bash security issue

On 09/25/2014 01:15 PM, Linda Walsh wrote: > Eric Blake wrote: >> And _that's_ what I want changed, by proposing that bash use 'f()=...' >> rather than 'f=() {...' as the magic it uses for exporting functions >> from parent to child. >> > --- > That could still be put in the environment (though

Re: Issues with exported functions

On Sep 25, 2014, at 2:47 PM, lolilolicon wrote: > On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote: > [...] >> On the other hand, this approach would be much more interesting if bash >> delayed parsing of exported functions until they are used (ie. check > > This is what function autoload

Re: Issues with exported functions

On 9/25/14, 2:47 PM, lolilolicon wrote: > On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote: > [...] >> On the other hand, this approach would be much more interesting if bash >> delayed parsing of exported functions until they are used (ie. check > > This is what function autoload is for in

Re: Issues with exported functions

On Fri, Sep 26, 2014 at 2:53 AM, Linda Walsh wrote: > --- > "prevert" _might_ have been more obviously seen as applicable to a bash > programmer who is "pre-bent" or "pre-twisted" from having programmed in > shell for so long, compared to the nick, lilololicon, with its 'H'y (as in > 'Hentai'-y)

Re: Issues with exported functions

> I'd much rather prefer the use of an invalid shell name (such as > f()=...) than a valid shell name (BASH_FUNCTION_foo=()...). Using a BASH_ prefix has some advantages: * Anyone setting such a variable, might expect it could change the behaviour of bash. Any script allowing setting untruste

Re: Issues with exported functions

> It's not backwards compatible, but who cares? The only time it > matters is if you are mixing old and new bash ON THE SAME SYSTEM, > and TRYING TO EXPORT FUNCTIONS BETWEEN THEM. It might happen during the update of bash. A bash process exec()ed before the update would fail to export a function

Building --enable-minimal-config fails: undefined reference to `glob_patscan'

Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba

Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)

Hello, I've downloaded the source for bash 4.3 and all patches, patched the source to Patch 25. But according some description I've found (http://heise.de/-2403305 sorry, only in German available), you can test with the command env x='() { :;}; echo vulnerable' bash -c "echo this is a test" i

CERT/NIST reveal level 10 bash alert today, 24 September 2014

Is the response (workarounds and patch) being discussed elsewhere ? (1) Patch Looking at the code, it seems that the problem is that in initialize_shell_variables(), when an inheritable function is detected in the environment by the "() {" prefix, we then directly call parse_and_execute(), on t

patchset to optionally disable function exports

I understand that some people might find function exports useful, but there is also some utility in being able to turn it off. I've added a configure flag, --disable-function-export which prevents bash from attempting to parse environment variables that look like functions upon startup. The defaul

Re: Issues with exported functions

> Not quite. While autoloaded functions are lazily evaluated, you have to > pay the price of searching $FPATH and loading them in every shell, and > there still has to be a mechanism to indicate which functions should be > autoloaded in each shell. How about lazy loading functions using the follow

Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014

On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote: > Is the response (workarounds and patch) being discussed elsewhere ? > > > (1) Patch > > Looking at the code, it seems that the problem is that in > initialize_shell_variables(), when an inheritable function is detected in > the environment by

Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)

On Thu, Sep 25, 2014 at 05:33:38PM +0200, ralf.naeg...@she.net wrote: > env x='() { :;}; echo vulnerable' bash -c "echo this is a test" Did you *install* the patched version so that it is the first "bash" in your PATH before running this? If not, you should specify a path to bash (e.g. ./bash -c

Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)

On 09/25/2014 09:33 AM, ralf.naeg...@she.net wrote: > Hello, > > I've downloaded the source for bash 4.3 and all patches, patched the source > to Patch 25. > But according some description I've found (http://heise.de/-2403305 sorry, > only in German > available), you can test with the command >

Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)

On Thu, Sep 25, 2014 at 05:33:38PM +0200, ralf.naeg...@she.net wrote: > Hello, > > I've downloaded the source for bash 4.3 and all patches, patched the source > to Patch 25. > But according some description I've found (http://heise.de/-2403305 sorry, > only in German > available), you can test

Re: Issues with exported functions

Chet Ramey wrote: > On 9/25/14, 2:47 PM, lolilolicon wrote: > > On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote: > > [...] > >> On the other hand, this approach would be much more interesting if bash > >> delayed parsing of exported functions until they are used (ie. check > > > > This is wh

Re: Bash-4.3 Official Patch 25

On 9/24/14, 5:38 PM, Eric Blake wrote: > and I'd feel much more comfortable with exporting f()=... as the > backdoor for passing the function definition, _particularly_ since the > shell already allows functions and variables to co-exist: We used to do that, and part of the code that I removed in

Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014

On 25/09/2014 22:51, Eric Blake wrote: On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote: Is the response (workarounds and patch) being discussed elsewhere ? (1) Patch Looking at the code, it seems that the problem is that in initialize_shell_variables(), when an inheritable function is dete

Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014

On Sep 25, 2014, at 5:42 PM, Alexandre FERRIEUX - SOFT/LAN wrote: > On 25/09/2014 22:51, Eric Blake wrote: >> On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote: >>> Is the response (workarounds and patch) being discussed elsewhere ? > > Thanks. Like thousands of people I guess, I have never ima

Re: Bash-4.3 Official Patch 25

On 09/25/2014 05:58 PM, Chet Ramey wrote: > On 9/24/14, 5:38 PM, Eric Blake wrote: > >> and I'd feel much more comfortable with exporting f()=... as the >> backdoor for passing the function definition, _particularly_ since the >> shell already allows functions and variables to co-exist: > > We us

Re: CERT/NIST reveal level 10 bash alert today, 24 September 2014

On 9/24/2014 6:07 PM, Thad Floryan wrote: > I caught the newsflash at Reuters earlier todat and a > search found the other URLs below. This seemed the only > relevant bash group available for subscription at the > eternal-september NNTP server. > > Articles: > > New 'Bash' software bug may pose

Re: Bash security issue

Eric Blake wrote: Where I'm coming from is that in portable shell programming, you _can't_ assign a value to f()=... The fact that portable programs are now "slammed"[sic] with the notion that some values cannot be portably assigned to a variable... --- slammed? It's not like this is new...

Bash --version issue

Earlier today I performed the `bash` security upgrade on my | [userid~]uname -rs | FreeBSD 10.0-RELEASE-p9 machine. I thought to check the version level of `bash` to see what I now have: | [userid~]man bash | : | : | --version | Show version information for this instance of ba

Re: Bash --version issue

On 9/25/14, 9:41 PM, Allodoxaphobia wrote: > Earlier today I performed the `bash` security upgrade on my > | [userid~]uname -rs > | FreeBSD 10.0-RELEASE-p9 > machine. I thought to check the version level of `bash` to > see what I now have: I can't reproduce this. My patched version of bash giv

Re: Bash --version issue

On Thu, 25 Sep 2014 23:04:46 -0400, Chet Ramey wrote: > On 9/25/14, 9:41 PM, Allodoxaphobia wrote: >> Earlier today I performed the `bash` security upgrade on my >> | [userid~]uname -rs >> | FreeBSD 10.0-RELEASE-p9 >> machine. I thought to check the version level of `bash` to >> see what I now h

Latest Patch

William Moss billm...@acm.org On my Debian system, they seem to have applied the fix for strcpy. On my custom system, I recompiled bash 4.2 from source and when I tried to apply the latest patch: patch -b -i ./bash42-048 -p0 -o ./bash I get patching file ./bash Hunk #1 succeeded at 36 with fuzz 2

Re: Bash-4.3 Official Patch 25

On Friday, September 26, 2014 9:58:56 AM UTC+10, Chet Ramey wrote: > On 9/24/14, 5:38 PM, Eric Blake wrote: > > > > > and I'd feel much more comfortable with exporting f()=... as the > > > backdoor for passing the function definition, _particularly_ since the > > > shell already allows functio

Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)

Hello Eduardo, I haven't installed the patched bash yet. I called it in the source directory after compiling, it with ./bash so I think this should start the patched bash. Regards, Ralf On Thu, 25 Sep 2014, Eduardo A. Bustamante López wrote: > Date: Thu, 25 Sep 2014 13:50:00 -0700 > From:

Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)

On 26/09/2014 08:23, Ralf Naegele wrote: Hello Eduardo, I haven't installed the patched bash yet. I called it in the source directory after compiling, it with ./bash so I think this should start the patched bash. You started ./bash as the parent reading the offending line, but did you also mo

Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)

Hello Greg, thanks for the hint, this seems to be the solution. I've copied the compiled bash binary to the first directory from $PATH output and now the test is ok: [naegele@pinie ~]$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definiti

Detecting invocation as /bin/sh ?

Hello, In the wake of the exported func bug, as can be seen in the nearby thread "Issues with exported functions", many people are just now discovering a host of things that bash does, of course in a documented way, but that they never needed in the first place. Of course, their intention is p