Detecting invocation as /bin/sh ?

[Alexandre Ferrieux]

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 precisely expressed by the '#!/bin/sh' header in 
scripts, but most major Unices today just have a symbolic link there (sh->bash).

So, what about, in bash's initialization, detecting that we are invoked as 
"/bin/sh", and disabling all those bells and whistles (or behaving as bash -p, 
which is a close approximation) ?

Note we already have something similar with the name "rbash" that triggers 
restricted mode:

  restricted_shell = shell_is_restricted (shell_name);

So I'm merely proposing to do the same with privileged_mode (or a close cousin 
if its side effects are too strong):

  privileged_mode = shell_is_legacy_sh (shell_name);

Reactions ?

-Alex

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

[Ralf Naegele]

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 definition attempt
bash: error importing function definition for `x'
this is a test

Regards,
Ralf

On Thu, 25 Sep 2014, Greg Wooledge wrote:

> Date: Thu, 25 Sep 2014 16:52:19 -0400
> From: Greg Wooledge 
> To: ralf.naeg...@she.net
> Cc: bug-bash@gnu.org
> Subject: 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 "echo ...").
> 

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

[Alexandre FERRIEUX - SOFT/LAN]

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 
modify it so that ./bash appears inside ?

env x='() { :;}; echo vulnerable' ./bash -c "echo this is a test"


This is important since the bug occurs in the child, at init time (within 
shell_initialize_variables)

-Alex

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

[Ralf Naegele]

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: Eduardo A. Bustamante López 
> To: ralf.naeg...@she.net
> Cc: bug-bash@gnu.org
> Subject: 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 with the command
> > 
> > env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
>
> Did you install the patched bash properly? If you forgot to install
> it, calling 'bash' will launch the still vulnerable version.
> 

Re: Bash-4.3 Official Patch 25

[mark]

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 functions and variables to co-exist:
> 
> 
> 
> We used to do that, and part of the code that I removed in patch 25
> 
> supported the original `name()=() {'.  We didn't use that very long; it
> 
> turns out that the Bourne shell (and others, at that time) dumps core on
> 
> malformed environment variable names.  It's why we stuck with shell
> 
> identifiers, though the check for that didn't come in until later.
> 
> 
> 
> I'd be willing to bet that the Bourne shell that still runs on Solaris,
> 
> AIX, HP-UX, and SCO (if anyone still runs that) has this problem.
> 
> -- 
> 
> ``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/


Not these Solaris ones :)


env x='() { :;}; echo vulnerable'  /usr/local/bin/bash -c "echo this is a test"
/usr/local/bin/bash: warning: x: ignoring function definition attempt
/usr/local/bin/bash: error importing function definition for `x'
this is a test

bash-4.3# (X='() { (a)=>\' bash -c "echo ls /etc; cat echo")
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
ls /etc
cat: cannot open echo

I've just issued the new Solaris packages on the archive.

http://www.ibiblio.org/pub/packages/solaris/sparc/

-rw---1 mark users 7463936 Sep 26 00:06 
bash.4.3.p026.SPARC.32bit.Solaris.10.pkg
-rw---1 mark users 7745024 Sep 26 00:06 
bash.4.3.p026.SPARC.32bit.Solaris.8.pkg
-rw---1 mark users 7750144 Sep 26 00:06 
bash.4.3.p026.SPARC.32bit.Solaris.9.pkg
-rw---1 mark users 7765504 Sep 26 00:06 
bash.4.3.p026.SPARC.64bit.Solaris.10.pkg
-rw---1 mark users 7968768 Sep 26 00:07 
bash.4.3.p026.SPARC.64bit.Solaris.11.pkg
-rw---1 mark users 8154112 Sep 26 00:07 
bash.4.3.p026.SPARC.64bit.Solaris.8.pkg
-rw---1 mark users 8147456 Sep 26 00:07 
bash.4.3.p026.SPARC.64bit.Solaris.9.pkg
-rw---1 mark users 7868416 Sep 26 00:07 
bash.4.3.p026.i86pc.64bit.Solaris.11.pkg
-rw---1 mark users 7700992 Sep 26 00:07 
bash.4.3.p026.i86pc.Solaris.10.pkg
-rw---1 mark users 7426560 Sep 26 00:07 
bash.4.3.p026.i86pc.Solaris.11.pkg

-rw---1 mark users 1685504 Sep 26 00:06 
readline.6.3.SPARC.32bit.Solaris.10.pkg
-rw---1 mark users 1706496 Sep 26 00:06 
readline.6.3.SPARC.32bit.Solaris.8.pkg
-rw---1 mark users 1715200 Sep 26 00:06 
readline.6.3.SPARC.32bit.Solaris.9.pkg
-rw---1 mark users 2161152 Sep 26 00:06 
readline.6.3.SPARC.64bit.Solaris.10.pkg
-rw---1 mark users 2287104 Sep 26 00:06 
readline.6.3.SPARC.64bit.Solaris.11.pkg
-rw---1 mark users 2199552 Sep 26 00:06 
readline.6.3.SPARC.64bit.Solaris.8.pkg
-rw---1 mark users 2196992 Sep 26 00:06 
readline.6.3.SPARC.64bit.Solaris.9.pkg
-rw---1 mark users 3524608 Sep 26 00:06 
readline.6.3.i86pc.64bit.Solaris.11.pkg
-rw---1 mark users 1645056 Sep 26 00:06 
readline.6.3.i86pc.Solaris.10.pkg
-rw---1 mark users 1554432 Sep 26 00:06 
readline.6.3.i86pc.Solaris.11.pkg

Latest Patch

[William Moss]

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.
patching file ./bash
Hunk #1 succeeded at 262 with fuzz 2.
Hunk #2 succeeded at 330 with fuzz 2.
patching file ./bash
Hunk #1 FAILED at 348.
Hunk #2 FAILED at 362.
2 out of 2 hunks FAILED -- saving rejects to file ./bash.rej
patching file ./bash
Hunk #1 FAILED at 26.
1 out of 1 hunk FAILED -- saving rejects to file ./bash.rej

Any ideas?
I also tried this w/ 4.1 and 4.3, same result.

Thank you.
BTW:
When I taught C at Bell Labs, in the mid 1980's, using strcpy() and
strncpy() rather than memcpy() was a common error.

Re: Bash --version issue

[Allodoxaphobia]

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 have:
>
> I can't reproduce this.  My patched version of bash gives
>
> $ ./bash --version
> GNU bash, version 4.3.26(3)-release (x86_64-apple-darwin13.1.0)
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> on Mac OS X.  You might ask the FreeBSD ports folks, since it will
> probably be a while before I can look at this.

Ya, as is often the case, some packages in the FreeBSD ports 
seem to be fiddled with by the time they get to the user.

Just recently I had an issue with alpine that-a-way.
Compiling it from the maintainer's source yielded a copy that 
did not have the bug I encountered with the ports package.

Thanks for the quick reply!
Jonesy
-- 
  Marvin L Jones| Marvin  | W3DHJ  | linux
   38.238N 104.547W |  @ jonz.net | Jonesy |  OS/2
* Killfiling google & banter.com: jonz.net/ng.htm

Re: Bash --version issue

[Chet Ramey]

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 gives

$ ./bash --version
GNU bash, version 4.3.26(3)-release (x86_64-apple-darwin13.1.0)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

on Mac OS X.  You might ask the FreeBSD ports folks, since it will
probably be a while before I can look at this.

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 --version issue

[Allodoxaphobia]

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 bash
 | on the standard output and exit successfully.
 |  :
 |  :
 | [userid~]bash --version
 | [userid@vps ~]$ exit
 | exit
 | [userid~]

I'm pretty sure it's worked ok here in the past -- for an unknown
value of $PAST.

With an older `bash` on an old linux workstation:

 | $ bash --version
 | GNU bash, version 4.1.5(1)-release

Jonesy
-- 
  Marvin L Jones| Marvin  | W3DHJ  | linux
   38.238N 104.547W |  @ jonz.net | Jonesy |  OS/2
* Killfiling google & banter.com: jonz.net/ng.htm

Re: Bash security issue

[Linda Walsh]

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...


Not much more secure, but ..'ƒ(8-byte-crypto-hex-sig)'
Overkill.  

---
Ya think?

I mean isn't the world held together by duct-tape, bailing-
wire and bash (or -compat) scripts?  Anyway, it was also meant
as a "if you really are serious about solving this and don't care
about the overhead or inconvenience..." illustration of panic-driven
design.

Eric Blake wrote:

It's not backwards compatible, but who cares? only matters
if you are mixing old and new bash...
 But the old bash behavior is so bad that  people are unlikely to 
want to have both shells installed.

---
Oh come on... "so bad"?

As other have said:

   «Geir Hauge wrote: Bash has had this feature since "forever"»

   «Pierre Gaston wrote:  How many instance have you found since the
introduction of this feature more than 20 years ago?»



This behavior has been around for 20+ without it being judged "so bad",
so lets not be tempted toward knee-jerk reactions.  That it is now known
about makes some protections more urgent, but panicking over security fixes
often results in stupid knee-jerk "fixes"[sic] that only need to be
re-fixed [fixed] later on.

That it is a bug that should be fixed, no argument.
Your idea of using "f()=" in the ENV is sounds reasonable (though
not nearly so elegant as using the unicode 'function' symbol, 'ƒ' instead of
empty parens, in memory (ENV) -- not as to what a user would type.
The '()' is already overloaded w/meaning, "null set", or "empty array
assignment", depending on context.

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

[Thad Floryan]

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 bigger threat than 'Heartbleed'
> http://www.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUSKCN0HJ2FQ20140924
> http://uk.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUKKCN0HJ2FQ20140924
> 
> Vulnerability Summary for CVE-2014-6271 - NVD - Detail
> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
> 
> Bourne Again Shell (Bash) Remote Code Execution Vulnerability
> https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability
> 
> Bourne Again Shell (Bash) Remote Code Execution ...
> http://www.pcisecuritypolicies.com/bourne-again-shell-bash-remote-code-execution-vulnerability/

There was another Reuters news update a short while ago today:

Hackers exploit 'Shellshock' bug with worms in early attacks
By Jim Finkle, Boston, Thu Sep 25, 2014 6:34pm EDT

http://www.reuters.com/article/2014/09/25/us-cybersecurity-shellshock-idUSKCN0HK23Y20140925

(Reuters) - Hackers have begun exploiting the newly identified
"Shellshock" computer bug, using fast-moving worm viruses to scan for
vulnerable systems and then infect them, researchers warned on Thursday.

"Shellshock" is the first major Internet threat to emerge since the
discovery in April of "Heartbleed," which affected OpenSSL encryption
software that is used in about two-thirds of all web servers, along with
hundreds of technology products for consumers and businesses.

The latest bug has been compared to "Heartbleed" partly because the
software at the heart of the "Shellshock" bug, known as Bash, is also
widely used in web servers and other types of computer equipment.

The problem is unlikely to affect as many systems as Heartbleed because
not all computers running Bash can be exploited, according to security
experts. Still, they said "Shellshock" has the potential to wreak more
havoc because it enables hackers to gain complete control of an infected
machine, which could allow hackers to destroy data, shut down networks
or launch attacks on websites, experts said.

The "Heartbleed" bug only allowed them to steal data.

The industry is rushing to determine which systems can be remotely
compromised by hackers, but there are currently no estimates on the
number of vulnerable systems.
[...]

{ article continues at above URL }

Thad

Re: Bash-4.3 Official Patch 25

[Eric Blake]

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 used to do that, and part of the code that I removed in patch 25
> supported the original `name()=() {'.  We didn't use that very long; it
> turns out that the Bourne shell (and others, at that time) dumps core on
> malformed environment variable names.  It's why we stuck with shell
> identifiers, though the check for that didn't come in until later.
> 
> I'd be willing to bet that the Bourne shell that still runs on Solaris,
> AIX, HP-UX, and SCO (if anyone still runs that) has this problem.

I just tested on Solaris 9 (the oldest machine I have easy access to),
and /bin/sh there silently ignored things without crashing:

$ env 'foo()=()' /bin/sh -c 'env | grep foo'
$ env 'foo()=()' bash -c 'env | grep foo'
foo()=()
$ uname -a
SunOS XX 5.9 Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise-T5220

While it may have been a problem in the past, I don't think systems old
enough to have an 'sh' that dumps core on odd environment variables are
still worth worrying about in the present.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

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

[Steve Simmons]

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 imagined before today 
> that a "bash bug" could exist, so I'm new to this list, and did not realized 
> its archive was lagging a bit. Sorry about re-asking.
> 
>> 
>>> (2) Workaround
>>> 
>>> Privileged mode skips the import of functions from the environment, hence
>>> "#! /bin/bash -p" is a quick fix.
>>> I assume that 99.9% of uses would be unaffected by the other side-effects
>>> of -p.
>>> Am I missing something ?
>> Yes.  Among others, system(3) and popen(3) call /bin/sh, if /bin/sh is
>> bash, there is no way for you to pass -p into that child.
> Argh indeed.
> 
> Out of curiosity, may I ask what purpose 'export -f' serves ? In 20+ years of 
> unix (admittedly sticking to /bin/sh for lack of a compelling need of 
> anything else), I have never felt the need to share function across a 
> fork/exec (across a fork, of course, in subshells; but not a fork/exec). So 
> what is that use-case that motivated that tricky feature ?

Check the archive; there was just a long discussion on this and it should be in 
there by now. Look for the subject 'Issues with exported functions'.

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

[Alexandre FERRIEUX - SOFT/LAN]

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 detected in
the environment by the "() {" prefix, we then directly
call parse_and_execute(), on the whole string.
Obviously this includes any trailing commands after "} ;". A proper fix
would need to tweak the parser to do a parse_and_execute_one_command().
Anybody already working along those lines ?

Official patches have already been released to stop parsing too far
(CVE-2014-6271), additional patches will be posted soon for the fact
that errors in the parser can still be exploited (CVE-2014-7169).
http://www.openwall.com/lists/oss-security/2014/09/ is discussing some
of the further patches that have already been proposed, to make sure
that we don't have yet a third round of updates required.


Thanks. Like thousands of people I guess, I have never imagined before today that a "bash bug" could exist, so I'm new 
to this list, and did not realized its archive was lagging a bit. Sorry about re-asking.





(2) Workaround

Privileged mode skips the import of functions from the environment, hence
"#! /bin/bash -p" is a quick fix.
I assume that 99.9% of uses would be unaffected by the other side-effects
of -p.
Am I missing something ?

Yes.  Among others, system(3) and popen(3) call /bin/sh, if /bin/sh is
bash, there is no way for you to pass -p into that child.

Argh indeed.

Out of curiosity, may I ask what purpose 'export -f' serves ? In 20+ years of unix (admittedly sticking to /bin/sh for 
lack of a compelling need of anything else), I have never felt the need to share function across a fork/exec (across a 
fork, of course, in subshells; but not a fork/exec). So what is that use-case that motivated that tricky feature ?


-Alex

Re: Bash-4.3 Official Patch 25

[Chet Ramey]

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 patch 25
supported the original `name()=() {'.  We didn't use that very long; it
turns out that the Bourne shell (and others, at that time) dumps core on
malformed environment variable names.  It's why we stuck with shell
identifiers, though the check for that didn't come in until later.

I'd be willing to bet that the Bourne shell that still runs on Solaris,
AIX, HP-UX, and SCO (if anyone still runs that) has this problem.
-- 
``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

[Ángel González]

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 what function autoload is for in zsh. It's indeed a better
> > approach. It was also suggested by Dan Douglas in this thread ("FPATH
> > mechanism").
> 
> 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.
> 
> Chet

I wasn't refering to storing the functions in files, but to lazily parse
the command from the environment. It wouldn't affect the way bash
functions are transfered.

See the naive implementation provided below:


diff --git a/variables.h b/variables.h
index 1a783b9..f496b9d 100644
--- a/variables.h
+++ b/variables.h
@@ -125,6 +125,7 @@ typedef struct _vlist {
 #define att_imported   0x0008000   /* came from environment */
 #define att_special0x001   /* requires special handling */
 #define att_nofree 0x002   /* do not free value on unset */
+#define att_unparsed   0x004   /* it was not parsed after loading from 
environ */
 
 #defineattmask_int 0x00ff000
 
@@ -153,6 +154,7 @@ typedef struct _vlist {
 #define imported_p(var)var)->attributes) & (att_imported)))
 #define specialvar_p(var)  var)->attributes) & (att_special)))
 #define nofree_p(var)  var)->attributes) & (att_nofree)))
+#define unparsed_p(var)var)->attributes) & (att_unparsed)))
 
 #define tempvar_p(var) var)->attributes) & (att_tempvar)))
 
diff --git a/variables.c b/variables.c
index 92a5a10..a0e42ff 100644
--- a/variables.c
+++ b/variables.c
@@ -351,34 +351,13 @@ initialize_shell_variables (env, privmode)
 the environment in privileged mode. */
   if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", 
string, 4))
{
- string_length = strlen (string);
- temp_string = (char *)xmalloc (3 + string_length + char_index);
 
- strcpy (temp_string, name);
- temp_string[char_index] = ' ';
- strcpy (temp_string + char_index + 1, string);
-
- /* Don't import function names that are invalid identifiers from the
-environment, though we still allow them to be defined as shell
-variables. */
- if (legal_identifier (name))
-   parse_and_execute (temp_string, name, 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
-
- if (temp_var = find_function (name))
-   {
- VSETATTR (temp_var, (att_exported|att_imported));
- array_needs_making = 1;
-   }
- else
-   {
- if (temp_var = bind_variable (name, string, 0))
+ if (temp_var = bind_function (name, 0))
{
- VSETATTR (temp_var, (att_exported | att_imported | 
att_invisible));
+ VSETATTR (temp_var, (att_exported | att_imported | 
att_unparsed));
+ SET_EXPORTSTR(temp_var, savestring (string));
  array_needs_making = 1;
}
- last_command_exit_value = 1;
- report_error (_("error importing function definition for `%s'"), 
name);
-   }
}
 #if defined (ARRAY_VARS)
 #  if ARRAY_EXPORT
@@ -1049,8 +1028,11 @@ print_var_function (var)
 
   if (function_p (var) && var_isset (var))
 {
-  x = named_function_string ((char *)NULL, function_cell(var), 
FUNC_MULTILINE|FUNC_EXTERNAL);
-  printf ("%s", x);
+ if (!maybe_parse_unparsed_func (var))
+   {
+  x = named_function_string ((char *)NULL, function_cell(var), 
FUNC_MULTILINE|FUNC_EXTERNAL);
+  printf ("%s", x);
+   }
 }
 }
 
@@ -3929,7 +3911,16 @@ make_env_array_from_var_list (vars)
   if (var->exportstr)
value = var->exportstr;
   else if (function_p (var))
-   value = named_function_string ((char *)NULL, function_cell (var), 0);
+   {
+ if (unparsed_p (var))
+   {
+ value = var->exportstr;
+   }
+ else
+   {
+ value = named_function_string ((char *)NULL, 
function_cell (var), 0);
+   }
+   }
 #if defined (ARRAY_VARS)
   else if (array_p (var))
 #  if ARRAY_EXPORT
diff --git a/execute_cmd.h b/execute_cmd.h
index 67ae93a..4f4e3ee 100644
--- a/execute_cmd.h
+++ b/execute_cmd.h
@@ -27,6 +27,7 @@ extern struct fd_bitmap *new_fd_bitmap __P((int));
 extern void dispose_fd_bitmap __P((struct fd_bitmap *));
 extern void close_fd_bitmap __P((struct fd_bitmap *));
 extern int executing_li

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

[Eduardo A . Bustamante López]

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 with the command
> 
> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Did you install the patched bash properly? If you forgot to install
it, calling 'bash' will launch the still vulnerable version.

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

[Eric Blake]

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
> 
> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Are you sure you are testing your just-built bash, and not whatever
version of bash happened to be first in your $PATH?

> 
> if your bash is vulnerable. But according this test the bash 4.3 with patch 
> 25 seems
> still vulnerable. I've tried this test with other Linux servers, where the 
> patched 
> bash binaries came from the repositories (Ubuntu, CentOS), where this test 
> now fails.
> 
> So my question: is bash in this version with patch 25 still vulnerable to 
> CVE-2014-6271?

No.  Patch 25 is what solves CVE-2014-6271 (but you will still need to
wait for Patch 26 before having a solution to the weaker CVE-2014-7169).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

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

[Greg Wooledge]

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 "echo ...").

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

[Eric Blake]

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 the "() {" prefix, we then directly
> call parse_and_execute(), on the whole string.
> Obviously this includes any trailing commands after "} ;". A proper fix
> would need to tweak the parser to do a parse_and_execute_one_command().
> Anybody already working along those lines ?

Official patches have already been released to stop parsing too far
(CVE-2014-6271), additional patches will be posted soon for the fact
that errors in the parser can still be exploited (CVE-2014-7169).
http://www.openwall.com/lists/oss-security/2014/09/ is discussing some
of the further patches that have already been proposed, to make sure
that we don't have yet a third round of updates required.

> 
> (2) Workaround
> 
> Privileged mode skips the import of functions from the environment, hence
> "#! /bin/bash -p" is a quick fix.
> I assume that 99.9% of uses would be unaffected by the other side-effects
> of -p.
> Am I missing something ?

Yes.  Among others, system(3) and popen(3) call /bin/sh, if /bin/sh is
bash, there is no way for you to pass -p into that child.  The set of
programs that set environment variables to user-controlled contents and
then fork a child process that may or may not use bash is shockingly
high.  Patching bash is much easier than trying to chase down every
invocation of bash to change those invocations to add -p.

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
is also a good read, as well as the archives of this list.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Issues with exported functions

[Eduardo A . Bustamante López]

> 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 following mechanism:

# code
foo arg1 arg2 arg3

1) Search for an alias called 'foo'
2) Search for a function named 'foo'
3) Search for a variable named 'foo' with '(){ ...; }' as contents
4) Search for a builtin ...
...

So far, this is compatible with what we already have, right?

Now, this method (of skipping the function definition until we
attempt to use it) could allow for a special shopt, which disables
the step '3'.

Something like: shopt -s nofunexp, which changes step 3 to

  3) Search for a variable named 'foo' with '(){ ...; }' as contents
  IF nofunexp is disabled.

So, I can now put: shopt -s nofunexp in my scripts proactively, to
avoid function exports at all.

Also, a special array variable could be introduced, like:

BASH_ALLOWED_FUNEXP=(foo bar baz), which acts as a whitelist to allow
only a certain set of functions to be taken from the environment.


So, this way, we keep backwards compatibility, but we also have the
opportunity to disallow exported functions.

-- 
Eduardo Bustamante

patchset to optionally disable function exports

[David Galos]

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 default behavior is still to allow
function exports. You can note that this actually adds symmetry with
array exports for which there is already a flag that does the same
thing.

Let me know if there is interest in this, or what I might need to do
further to get this accepted.


Thanks,
Dave
From 9f8f691304329618556c8c33dfc0b30cd10fcf26 Mon Sep 17 00:00:00 2001
From: David Galos 
Date: Thu, 25 Sep 2014 13:27:43 -0400
Subject: [PATCH 1/4] add a flag to enable or disable function import on
 startup

---
 configure.in | 6 ++
 variables.c  | 4 
 2 files changed, 10 insertions(+)

diff --git a/configure.in b/configure.in
index d7e0998..c48bf07 100644
--- a/configure.in
+++ b/configure.in
@@ -186,6 +186,7 @@ opt_single_longdoc_strings=yes
 opt_casemod_attrs=yes
 opt_casemod_expansions=yes
 opt_extglob_default=no
+opt_function_export=yes
 
 dnl options that affect how bash is compiled and linked
 opt_static_link=no
@@ -206,6 +207,7 @@ if test $opt_minimal_config = yes; then
 	opt_net_redirs=no opt_progcomp=no opt_separate_help=no
 	opt_multibyte=yes opt_cond_regexp=no opt_coproc=no
 	opt_casemod_attrs=no opt_casemod_expansions=no opt_extglob_default=no
+	opt_function_export=no
 fi
 
 AC_ARG_ENABLE(alias, AC_HELP_STRING([--enable-alias], [enable shell aliases]), opt_alias=$enableval)
@@ -241,6 +243,7 @@ AC_ARG_ENABLE(single-help-strings, AC_HELP_STRING([--enable-single-help-strings]
 AC_ARG_ENABLE(strict-posix-default, AC_HELP_STRING([--enable-strict-posix-default], [configure bash to be posix-conformant by default]), opt_strict_posix=$enableval)
 AC_ARG_ENABLE(usg-echo-default, AC_HELP_STRING([--enable-usg-echo-default], [a synonym for --enable-xpg-echo-default]), opt_xpg_echo=$enableval)
 AC_ARG_ENABLE(xpg-echo-default, AC_HELP_STRING([--enable-xpg-echo-default], [make the echo builtin expand escape sequences by default]), opt_xpg_echo=$enableval)
+AC_ARG_ENABLE(function-export, AC_HELP_STRING([--enable-function-export], [allow bash to treat certain environment variables as functions]), opt_function_export=$enableval)
 
 dnl options that alter how bash is compiled and linked
 AC_ARG_ENABLE(mem-scramble, AC_HELP_STRING([--enable-mem-scramble], [scramble memory on calls to malloc and free]), opt_memscramble=$enableval)
@@ -333,6 +336,9 @@ fi
 if test $opt_casemod_expansions = yes; then
 AC_DEFINE(CASEMOD_EXPANSIONS)
 fi
+if test $opt_function_export = yes; then
+AC_DEFINE(FUNCTION_EXPORT)
+fi
 
 if test $opt_memscramble = yes; then
 AC_DEFINE(MEMSCRAMBLE)
diff --git a/variables.c b/variables.c
index 92a5a10..f33f66c 100644
--- a/variables.c
+++ b/variables.c
@@ -349,7 +349,11 @@ initialize_shell_variables (env, privmode)
 
   /* If exported function, define it now.  Don't import functions from
 	 the environment in privileged mode. */
+#if defined (FUNCTION_EXPORT)
   if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
+#else
+  if (0)
+#endif
 	{
 	  string_length = strlen (string);
 	  temp_string = (char *)xmalloc (3 + string_length + char_index);
-- 
2.1.0.rc2.206.gedb03e5

From 0f6618bfd1a714b10205b20bb682e4de21a2a7f0 Mon Sep 17 00:00:00 2001
From: David Galos 
Date: Thu, 25 Sep 2014 13:41:35 -0400
Subject: [PATCH 2/4] merge configure.in changes to configure.ac

---
 configure.ac | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 97e8e04..2b116f8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -193,6 +193,7 @@ opt_casemod_expansions=yes
 opt_extglob_default=no
 opt_dircomplete_expand_default=no
 opt_globascii_default=no
+opt_function_export=yes
 
 dnl options that affect how bash is compiled and linked
 opt_static_link=no
@@ -213,7 +214,7 @@ if test $opt_minimal_config = yes; then
 	opt_net_redirs=no opt_progcomp=no opt_separate_help=no
 	opt_multibyte=yes opt_cond_regexp=no opt_coproc=no
 	opt_casemod_attrs=no opt_casemod_expansions=no opt_extglob_default=no
-	opt_globascii_default=no
+	opt_globascii_default=no opt_function_export=no
 fi
 
 AC_ARG_ENABLE(alias, AC_HELP_STRING([--enable-alias], [enable shell aliases]), opt_alias=$enableval)
@@ -251,6 +252,7 @@ AC_ARG_ENABLE(single-help-strings, AC_HELP_STRING([--enable-single-help-strings]
 AC_ARG_ENABLE(strict-posix-default, AC_HELP_STRING([--enable-strict-posix-default], [configure bash to be posix-conformant by default]), opt_strict_posix=$enableval)
 AC_ARG_ENABLE(usg-echo-default, AC_HELP_STRING([--enable-usg-echo-default], [a synonym for --enable-xpg-echo-default]), opt_xpg_echo=$enableval)
 AC_ARG_ENABLE(xpg-echo-default, AC_HELP_STRING([--enable-xpg-echo-default], [make the echo builtin expand escape sequences by default]), opt_xpg_echo=$enableval)
+AC_ARG_ENABL

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

[ralf . naegele]

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"

if your bash is vulnerable. But according this test the bash 4.3 with patch 25 
seems
still vulnerable. I've tried this test with other Linux servers, where the 
patched 
bash binaries came from the repositories (Ubuntu, CentOS), where this test now 
fails.

So my question: is bash in this version with patch 25 still vulnerable to 
CVE-2014-6271?

With kind regards,
Ralf

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux pinie 2.6.18.8-0.3-default #1 SMP Tue Apr 17 08:42:35 UTC 
2007 i686 athlon i386 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 4.3
Patch Level: 25
Release Status: release

Description:
[Detailed description of the problem, suggestion, or complaint.]

Repeat-By:
[Describe the sequence of events that causes the problem
to occur.]

Fix:
[Description of how to fix the problem.  If you don't know a
fix for the problem, don't include this section.]

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

[Alexandre Ferrieux]

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 the whole string.
Obviously this includes any trailing commands after "} ;". A proper fix
would need to tweak the parser to do a parse_and_execute_one_command().
Anybody already working along those lines ?

(2) Workaround

Privileged mode skips the import of functions from the environment, hence
"#! /bin/bash -p" is a quick fix.
I assume that 99.9% of uses would be unaffected by the other side-effects
of -p.
Am I missing something ?

-Alex

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

[michael]

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='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux fangorn 3.14.3 #10 SMP Fri Jun 27 23:41:04 CEST 2014 i586 
GNU/Linux
Machine Type: i586-pc-linux-gnu

Bash Version: 4.3
Patch Level: 25
Release Status: release

Description:
Building bash as minimal shell fails due to glob_patscan missing
The configuration information refers to a full features build, not to 
the
minimal build.

Repeat-By:
./configure --enable-minimal-config --disable-debugger
make
While linking, I get:
./lib/glob/libglob.a(gmisc.o): In function `glob_dirscan':
bash-4.3/lib/glob/gmisc.c:398: undefined reference to `glob_patscan'

Fix:
Workaround: Add --enable-extended-glob

Re: Issues with exported functions

[Gabriel Corona]

> 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 to a bash process
exec()ed after the update.

-- 
Gabriel

Re: Issues with exported functions

[Gabriel Corona]

> 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 untrusted BASH_
   variables to untrusted values should probably expect bad things to
   happen.

 * Anyone seeing such a variable (in env) might expect it to change
   the behaviour of bash. If I see foo(), in env I would probably not
   think "Of course, it will change bash behaviour."

 * It avoids name clashes: whateversh might want to use foo() for its
   own (different) purpose.

Maybe both could be used, BASH_FUNCTION_foo()?

Is there any portability issue with using '()' on some OSes?

-- 
Gabriel

Re: Issues with exported functions

[lolilolicon]

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)
> connotations it might invoke about someone who might be just a bit too
> "pedo-friendly" or pedo-'filic' (unless everyone knows the inside humor).

LOL, you're reinforcing my opinion of your style of argument, but I'll keep
that to myself. BUT you spelt my nick wrong :(

[...]
> My only issue "with" function export is it being a partial solution,
> missing Aliases (first and foremost) which, for some things, are more
> essential than functions, and missing Array and Hash export -- which have
> to be annoyingly emulated and reconstructed between commands.

What you're proposing here is the polar opposite of most people's
reaction to this bug; many are asking for a way to disable function
export, an obscure feature they never expected from bash.

I'm not sure how you want other kinds of export to work. I suppose you
want them to be inherited from the env? Then you want to invent a
protocol / syntax / minilanguage for bash to export and import those.
This is IMO not what the env is suitable for, since it's meant to be used
as a very simple and flat "name=value" format for passing environment
variables around. But maybe you can elaborate?

>
> Redoing those with each command is equally painful and requires their
> redefinition with each bash invocation via BASH_ENV.  But the number of
> redefines to work around those deficits is insignificant to the number of
> functions that rely on persistence, so simple scripts like this work:
>
> ---show_inc.sh---
> #!/bin/bash   include stdalias
> include Util/url
>
> #definitions are important
> int a=1+1
> string astring=1+1
> a+=1+1
> astring+=1+1
> printf "Integers: 1+1+1+1 = %s.  Strings: 1+1+1+1 = %s\n" "$a" "$astring"
>
> #2nd example
> include Util/url
>
> string url="http://google.com/foo";
>
> echo "proto=$(protocol "$url"), host=$(host "$url"), path=$(path "$url")"

Wow. That's advanced...
It looks like you have built a language on top of bash. Perhaps, just
maybe, your needs have outgrown what bash can reasonably provide?
(Feel free to dismiss this, I know this is a subjective thing.)

Re: Issues with exported functions

[Chet Ramey]

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 zsh. It's indeed a better
> approach. It was also suggested by Dan Douglas in this thread ("FPATH
> mechanism").

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.

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

[Steve Simmons]

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 is for in zsh. It's indeed a better
> approach. It was also suggested by Dan Douglas in this thread ("FPATH
> mechanism").

Autoload has plusses and minuses. Shell startup is initially faster because 
there's a lot less processing, but each not-yet-loaded function requires 
traversal of another search path. And if you have multiple levels of shell 
(who, me do :sh in vi?) any newly spawned shells in the same session don't get 
the previously loaded functions. Unless, of course, autoloaded functions could 
be exported. But I'm not gonna think about that right now, got a lot of work to 
do.

Re: Bash security issue

[Eric Blake]

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 not as easily w/o
> special code).

Where I'm coming from is that in portable shell programming, you _can't_
assign a value to f()=... (yes, 'env' can be used to pass non-shell
variables, but that is already non-portable).  The fact that portable
programs are now slammed with the notion that some values cannot be
portably assigned to a variable is what gets avoided by not using
portable variable names as the mechanism for passing function
definitions between parent and child.

> 
> Not that it is any more secure but how about replacing '()' with
> 'ƒ(8-byte-hex-sig)'
> that is some crypto-sig of the function?  If it matches the function's
> sig, then function
> would be read in.  Of course like any crypto function, it's crackable,
> but to toss
> in enough bits to really forestall that, would be prohibitive unless
> done on a
> whole 'block' of imported info, i.e.

Overkill.  The security hole arises because the problem, as it currently
exists, is triggerable by ANY portable environment variable definition.
 It is very easy to trick programs, particularly programs running on
other machines or with elevated privileges into defining a normal shell
variable environment variable of ANY name, and when that variable then
gets eval'd and triggers any bug in the bash parser, the attacker has
gained control.  As soon as you've made function passing require
something that can't be used as a normal shell variable, you don't have
to go any further.  Portable programs now no longer have to vet what
they store into regular variable names, and scrubbing an environment for
non-shell names is also fairly easy.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Bash security issue

[Linda Walsh]

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 more secure but how about replacing '()' with 
'ƒ(8-byte-hex-sig)'
that is some crypto-sig of the function?  If it matches the function's 
sig, then function
would be read in.  Of course like any crypto function, it's crackable, 
but to toss
in enough bits to really forestall that, would be prohibitive unless 
done on a

whole 'block' of imported info, i.e.

For more security, one could use cryptographic signing of a sequence of
BASH keys with the public key left in the environment and private key left
in a trusted kernel tpm keyring...(god that sounds painful -- but would like
by the method to really tie this down if that was really needed).  But 
script

isn't supposed to be the last line defense against launching the missiles.

Re: Issues with exported functions

[Linda Walsh]

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 remarks too seriously.

 *adds "pervert" & "like a girl" to List of Forbidden Terms in Public
 Mail*

 Thank you.

---
"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)

connotations it might invoke about someone who might be just a bit too
"pedo-friendly" or pedo-'filic' (unless everyone knows the inside humor).
As for the other phrase... are you from australia as a first guess, maye
euro as a 2nd?  Needless, one needs to make context and humor extra
clear in an international audience (not that I always am a master of
subtlety in such).


 I do not think about optimization. My opinion is the need for the
 programmer to think about optimization (that's not relevant to the
 problem at hand) is a symptom of bad design (of the language / tool), or
 perhaps the programmer is using wrong tool / using the tool wrong.


Spoilt youngster!... Bash is an interpreter and not noted for being
a high-speed scripting language.



 As to your particular argument for completions: I think zsh optimizes
 for this with autoloading mechanism, which is a better design.


---
Bash has an autoloading mechanism that people don't use because it's
usually faster to put a bunch of defs in 1 place than spread them over
1000 files.  For interactive use (which is zsh's emphasis), it's fine, but
for something that is as often used as a batch-control language as often
as interactively (like bash), its not.  Zsh isn't a backbone scripting
language.



 Isn't the mere fact that you have to do this round-around thing to
 "program safely" a proof by demonstration that exported functions are
 trouble?


===

Cf.: Isn't the mere fact that you need to use a "safe path" demonstrate
that PATH lookup is trouble?  OTOH, using abs-paths is just as problem
laden.  That you need to use safety precautions to generate robust
programs is "par for the course".

Everything has its up and down side(s).  By defining the programs I will
need as aliases up front, the program will die earlier if it's
requirements are not present.

Nevertheless, I'll redefine progs as functions nearly as often so I can
make a program easier to call (aliases are limited to the easiest stuff)
from my script.

Other functions redefine commands for a login session.  I don't want them
undefined on sub commands.  I'd prefer aliases be exportable (as well as
arrays and hashes).  If my sub commands are built on others, they'd all go
belly-up after the first exec -- more so than when sudo kills them off:

like "rd" for rmdir or "+x" for chmod +x -- both of which I need as
often with a sudo before them as not (and that tend to fail due to
sudo's inability to parse aliases or functions).

To give you an idea of function and definition that is skipped at login
vs.  not:


 time bash 2>/dev/null <
xxx
0.00sec 0.00usr 0.00sys (88.59% cpu)


 time bash -i 2>/dev/null <
xxx User .bashrc called 2nd time
0.21sec 0.14usr 0.05sys (93.21% cpu)





Setting up things only 1 time saves considerable time depending on
how much is setup for an interactive shell vs. not.

Also if my script uses 'sudo' it has to pay such penalties unless I patch
sudo.  I'll have scripts that make tons of calls to sudo because the rest
was designed to operate w/o privs and I try to isolate priv calls, so an
unpatch sudo that doesn't preserve environment when told to is a problem.

My only issue "with" function export is it being a partial solution,
missing Aliases (first and foremost) which, for some things, are more
essential than functions, and missing Array and Hash export -- which have
to be annoyingly emulated and reconstructed between commands.

Redoing those with each command is equally painful and requires their
redefinition with each bash invocation via BASH_ENV.  But the number of
redefines to work around those deficits is insignificant to the number of
functions that rely on persistence, so simple scripts like this work:

---show_inc.sh---
#!/bin/bash   
include stdalias

include Util/url

#definitions are important
int a=1+1
string astring=1+1
a+=1+1
astring+=1+1
printf "Integers: 1+1+1+1 = %s.  Strings: 1+1+1+1 = %s\n" "$a" "$astring"

#2nd example
include Util/url

string url="http://google.com/foo";

echo "proto=$(protocol "$url"), host=$(host "$url"), path=$(path "$url")"
---run---
/tmp> show_inc.sh
Integers: 1+1+1+1 = 4.  Strings: 1+1+1+1 = 1+11+1
proto=http, host=google.com, path=fooshow_inc.sh
---

(Yes, I included Util/url twice to show the effect of doing so).

Not only are exported functions a useful timesaver, but aliases, ar

Re: Issues with exported functions

[lolilolicon]

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 suggested by Dan Douglas in this thread ("FPATH
mechanism").

Re: Issues with exported functions

[Ángel González]

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_login. Fast. Very fast. But without 
> exportable functions, it wouldn't work at all.
> 
> As an exercise for the student, consider the utility of this simplified 
> excerpt:
> 
> for SYSTEM in \
>   {foo,bar,baz}.dec.school.edu \
>   {alligator,snake-skin,lizard}.reptiles.work.com \
>   {misery,serenity,frailty}.films.home.org \
> ; do # Strip off domain, use dash-less name as function name
>   export FNAME=${SYSTEM%%.*}
>   export FNAME=${FNAME//-/}
>   eval $(echo "$FNAME() { ssh $SYSTEM" '"$@";};'" export -f $FNAME")
>   unset SYSTEM FNAME
> done
> 
> Hint - source those lines, then give the command 'builtin type snakeskin'.
> 
> It's probably too much overhead for every bash invocation, but if you only do 
> it once per session, it's damned useful. 

Is it so much overhead? You are replacing the cost of a bash for loop
(and its two assignations, one export and one unset per iteration) with
the same loop performed in C.

It doesn't seem such a big win, I think you would need to do a more
heavy computation outside the eval for that. Note that if we enter in
micro-optimization measuring, you should also measure the slowing to
every program which need to ignore those hundreds of environment
variables.



On the other hand, this approach would be much more interesting if bash
delayed parsing of exported functions until they are used (ie. check
that they begin with "() {" and store the string as an 'unparsed
function', only parsing them the first time it gets executed in the
process).

This should give a nice speed up when there are exported functions
(parsing is **slow**), and would have avoided the CVE as well. What do
you think, Chet?



FWIW, for this specific example, instead of using bash functions I would
have done that in ssh_config(5).

Host foo bar baz
HostName %h.dec.school.edu

Host alligator snake-skin lizard
HostName %h.reptiles.work.com

Host misery serenity frailty
HostName %h.films.home.org


Yes, you would need to type "ssh snake-skin" instead of "snakeskin" but
they will autocomplete, and also allows to use them on other commands,
which your functions don't cover, like scp, sftp, rsync, svn, hg, git…


Best regards

Re: Bash security issue

[Eric Blake]

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/bash_shell_vuln/";.
>>>
>>> Take care that the environment is carefully vetted.
>>
>> There's nothing that ./configure can do to avoid the buggy bash, but it
>> may indeed be worth patching autoconf to generate configure scripts that
>> issue a loud warning if the buggy shell is detected on the user's
>> system.  I'll look into doing that.
> 
> The most surprising thing I learned from this whole ordeal is that
> there are strings consisting entirely of printable characters that
> are not portable to store in exported shell variables.

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.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Issues with exported functions

[Eric Blake]

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 invalid shell name (such as
f()=...) than a valid shell name (BASH_FUNCTION_foo=()...).

>>
>>  * still expand the variable if it matches the 'exported function'
>>pattern.
> 
> Yes, that's one of the approaches under consideration.  It raises the
> bar for abuse by requiring that an attacker be able to create environment
> variables with arbitrary names as well as values.  It is not,
> unfortunately, backwards compatible.

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.  But the old bash behavior is so bad that
people are unlikely to want to have both shells installed.  As long as
you have only new bash installed, then all parent-child relationships
will both understand the SAME interpretation of 'f()=...' in the
environment as a way to export shell functions, and leave 'f=() {...' as
a raw normal variable and avoid intruding on the user's possible string
space.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Issues with exported functions

[Dan Douglas]

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 examples/functions/autoload.*. I believe it serves 
> > mostly the same purpose as exported functions.
> 
> I have thought about it, but it is even less backwards compatible than
> the other suggestions.

True.

I guess one key point is that it's "lazy" and only gets checked if a command 
doesn't exist. A user could implement function import entirely by means of 
command_not_found_handle - searching only for a function with the name given 
in "$1", which should be inherently more secure than looking at every variable 
at startup.

-- 
Dan Douglas

Re: Issues with exported functions

[Chet Ramey]

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 purpose as exported functions.

I have thought about it, but it is even less backwards compatible than
the other suggestions.

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

[Dan Douglas]

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);
> > 
> >  * still expand the variable if it matches the 'exported function'
> >pattern.
> 
> Yes, that's one of the approaches under consideration.  It raises the
> bar for abuse by requiring that an attacker be able to create environment
> variables with arbitrary names as well as values.  It is not,
> unfortunately, backwards compatible.
> 

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 purpose as exported functions.

-- 
Dan Douglas

Re: Issues with exported functions

[lolilolicon]

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.

*adds "pervert" & "like a girl" to List of Forbidden Terms in Public Mail*

Thank you.

Re: Bash-4.3 Official Patch 25

[Jason Vas Dias]

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, which was the list file.
Sorry, my mistake - a nasty coincindence that it was the first
thing I tried with the new bash version.
Regards,
Jason

On 9/25/14, Jason Vas Dias  wrote:
> 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 x86_64 (Haswell) 8-core platform .
>
> 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 line; do
> tty;
> done < test.list
> 
>
> Its output illustrates the problem:
>
> 
> $ ./bash /tmp/t.sh
> /dev/pts/6
> not a tty
> not a tty
> 
>
> This bug seems to have infected the latest Ubuntu bash release also,
> which was created and pushed out  today with the  bash43-025 fix
> for the CVE-2014-6271 issue :
> 
> $ /bin/bash /tmp/t.sh
> /dev/pts/6
> not a tty
> not a tty
> 
> (/bin/bash is from the bash-4.3-7ubuntu1.1 package) .
>
> But /dev/fd/1 remains the same file :
> 
> #!/bin/bash
> tty
> ls -l /dev/fd/1;
> echo $'1\n2' > test.list;
> while read line; do
> tty;
> ls -l /dev/fd/1;
> done < test.list
> 
> Its output under Ubuntu bash:
>
> $ /bin/bash /tmp/tsh
> /dev/pts/6
> lrwx-- 1 jvasdias jvd 64 Sep 25 14:47 /dev/fd/1 -> /dev/pts/6
> not a tty
> lrwx-- 1 jvasdias jvd 64 Sep 25 14:47 /dev/fd/1 -> /dev/pts/6
> not a tty
> lrwx-- 1 jvasdias jvd 64 Sep 25 14:47 /dev/fd/1 -> /dev/pts/6
>
> This is rather confusing !
> Any ideas what may the the issue here ?
>
> Thanks & Regards,
> Jason
>
>
>
> On 9/24/14, Chet Ramey  wrote:
>>   BASH PATCH REPORT
>>   =
>>
>> Bash-Release:4.3
>> Patch-ID:bash43-025
>>
>> Bug-Reported-by: Stephane Chazelas 
>> Bug-Reference-ID:
>> Bug-Reference-URL:
>>
>> Bug-Description:
>>
>> Under certain circumstances, bash will execute user code while processing
>> the
>> environment for exported function definitions.
>>
>> Patch (apply with `patch -p0'):
>>
>> *** ../bash-4.3-patched/builtins/common.h2013-07-08 16:54:47.0
>> -0400
>> --- builtins/common.h2014-09-12 14:25:47.0 -0400
>> ***
>> *** 34,37 
>> --- 49,54 
>>   #define SEVAL_PARSEONLY0x020
>>   #define SEVAL_NOLONGJMP 0x040
>> + #define SEVAL_FUNCDEF  0x080   /* only allow function 
>> definitions */
>> + #define SEVAL_ONECMD   0x100   /* only allow a single command 
>> */
>>
>>   /* Flags for describe_command, shared between type.def and command.def
>> */
>> *** ../bash-4.3-patched/builtins/evalstring.c2014-02-11
>> 09:42:10.0
>> -0500
>> --- builtins/evalstring.c2014-09-14 14:15:13.0 -0400
>> ***
>> *** 309,312 
>> --- 313,324 
>>struct fd_bitmap *bitmap;
>>
>> +  if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)
>> +{
>> +  internal_warning ("%s: ignoring function definition attempt",
>> from_file);
>> +  should_jump_to_top_level = 0;
>> +  last_result = last_command_exit_value = EX_BADUSAGE;
>> +  break;
>> +}
>> +
>>bitmap = new_fd_bitmap (FD_BITMAP_SIZE);
>>begin_unwind_frame ("pe_dispose");
>> ***
>> *** 369,372 
>> --- 381,387 
>>dispose_fd_bitmap (bitmap);
>>discard_unwind_frame ("pe_dispose");
>> +
>> +  if (flags & SEVAL_ONECMD)
>> +break;
>>  }
>>  }
>> *** ../bash-4.3-patched/variables.c  2014-05-15 08:26:50.0 -0400
>> --- variables.c  2014-09-14 14:23:35.0 -0400
>> ***
>> *** 359,369 
>>strcpy (temp_string + char_index + 1, string);
>>
>> !  if (posixly_correct == 0 || legal_identifier (name))
>> !parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
>> !
>> !  /* Ancient backwards compatibility.  Old versions of bash exported
>> ! functions like name()=() {...} */
>> !  if (name[char_index - 1] == ')' && name[char_index - 2] == '(')
>> !name[char_index - 2] = '\0';
>>
>>if (temp_var = find_function (name))
>> --- 364,372 
>>strcpy (temp_string + char_index + 1, string);
>>
>> !  /* Don't import function names that are invalid identifiers from the
>> ! environment, though we still allow them to be defined as s

Re: Bash-4.3 Official Patch 25

[Andreas Schwab]

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 think this
has anything to do with this patch?

$ tty --help | head -n 2
Usage: tty [OPTION]...
Print the file name of the terminal connected to standard input.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Bash-4.3 Official Patch 25

[Greg Wooledge]

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 line; do
> tty;
> done < test.list
> 

Well, that's because you have redirected stdin.  Try this instead:

while read line <&3; do
tty
done 3< test.list

Re: Bash-4.3 Official Patch 25

[Jason Vas Dias]

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 x86_64 (Haswell) 8-core platform .

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 line; do
tty;
done < test.list


Its output illustrates the problem:


$ ./bash /tmp/t.sh
/dev/pts/6
not a tty
not a tty


This bug seems to have infected the latest Ubuntu bash release also,
which was created and pushed out  today with the  bash43-025 fix
for the CVE-2014-6271 issue :

$ /bin/bash /tmp/t.sh
/dev/pts/6
not a tty
not a tty

(/bin/bash is from the bash-4.3-7ubuntu1.1 package) .

But /dev/fd/1 remains the same file :

#!/bin/bash
tty
ls -l /dev/fd/1;
echo $'1\n2' > test.list;
while read line; do
tty;
ls -l /dev/fd/1;
done < test.list

Its output under Ubuntu bash:

$ /bin/bash /tmp/tsh
/dev/pts/6
lrwx-- 1 jvasdias jvd 64 Sep 25 14:47 /dev/fd/1 -> /dev/pts/6
not a tty
lrwx-- 1 jvasdias jvd 64 Sep 25 14:47 /dev/fd/1 -> /dev/pts/6
not a tty
lrwx-- 1 jvasdias jvd 64 Sep 25 14:47 /dev/fd/1 -> /dev/pts/6

This is rather confusing !
Any ideas what may the the issue here ?

Thanks & Regards,
Jason



On 9/24/14, Chet Ramey  wrote:
>BASH PATCH REPORT
>=
>
> Bash-Release: 4.3
> Patch-ID: bash43-025
>
> Bug-Reported-by:  Stephane Chazelas 
> Bug-Reference-ID:
> Bug-Reference-URL:
>
> Bug-Description:
>
> Under certain circumstances, bash will execute user code while processing
> the
> environment for exported function definitions.
>
> Patch (apply with `patch -p0'):
>
> *** ../bash-4.3-patched/builtins/common.h 2013-07-08 16:54:47.0
> -0400
> --- builtins/common.h 2014-09-12 14:25:47.0 -0400
> ***
> *** 34,37 
> --- 49,54 
>   #define SEVAL_PARSEONLY 0x020
>   #define SEVAL_NOLONGJMP 0x040
> + #define SEVAL_FUNCDEF   0x080   /* only allow function 
> definitions */
> + #define SEVAL_ONECMD0x100   /* only allow a single command 
> */
>
>   /* Flags for describe_command, shared between type.def and command.def */
> *** ../bash-4.3-patched/builtins/evalstring.c 2014-02-11 09:42:10.0
> -0500
> --- builtins/evalstring.c 2014-09-14 14:15:13.0 -0400
> ***
> *** 309,312 
> --- 313,324 
> struct fd_bitmap *bitmap;
>
> +   if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)
> + {
> +   internal_warning ("%s: ignoring function definition attempt",
> from_file);
> +   should_jump_to_top_level = 0;
> +   last_result = last_command_exit_value = EX_BADUSAGE;
> +   break;
> + }
> +
> bitmap = new_fd_bitmap (FD_BITMAP_SIZE);
> begin_unwind_frame ("pe_dispose");
> ***
> *** 369,372 
> --- 381,387 
> dispose_fd_bitmap (bitmap);
> discard_unwind_frame ("pe_dispose");
> +
> +   if (flags & SEVAL_ONECMD)
> + break;
>   }
>   }
> *** ../bash-4.3-patched/variables.c   2014-05-15 08:26:50.0 -0400
> --- variables.c   2014-09-14 14:23:35.0 -0400
> ***
> *** 359,369 
> strcpy (temp_string + char_index + 1, string);
>
> !   if (posixly_correct == 0 || legal_identifier (name))
> ! parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
> !
> !   /* Ancient backwards compatibility.  Old versions of bash exported
> !  functions like name()=() {...} */
> !   if (name[char_index - 1] == ')' && name[char_index - 2] == '(')
> ! name[char_index - 2] = '\0';
>
> if (temp_var = find_function (name))
> --- 364,372 
> strcpy (temp_string + char_index + 1, string);
>
> !   /* Don't import function names that are invalid identifiers from the
> !  environment, though we still allow them to be defined as shell
> !  variables. */
> !   if (legal_identifier (name))
> ! parse_and_execute (temp_string, name,
> SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
>
> if (temp_var = find_function (name))
> ***
> *** 382,389 
> report_error (_("error importing function definition for `%s'"),
> name);
>   }
> -
> -   /* ( */
> -   if (name[char_index - 1] == ')' && name[char_index - 2] == '\0')
> - name[char_index - 2] = '('; /* ) */
>   }
>   #if defined (ARRAY_VARS)
> --- 385,388 
> *** ../bash-4.3-patched/subst.c   2014-08-11 11:16:35.0 -0400
> --- subst.c   2014-09-12 15:3

Re: Bash-4.3 Official Patch 25

[M1ch34lk]

>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

[Chet Ramey]

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 unrelated problem -- I can get to it via a different code
path -- with a simple fix.  I've attached it.

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-20140912/parse.y	2014-08-26 15:09:42.0 -0400
--- parse.y	2014-09-24 22:47:28.0 -0400
***
*** 2959,2962 
--- 2959,2964 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';		/* XXX */
last_read_token = '\n';

Re: Bash-4.3 Official Patch 25

[Mark Ashley]

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, 24 Sep 2014, m...@ibiblio.org wrote:
>
>
>>  Bash-Release:4.3
>>> Patch-ID:bash43-025
>>>
>>
>> As a binary distribution archive maintainer, I'd be keen to see the
>> authors distributing a cumulative bash-4.3p025.tar.gz source bundle
>> (probably p026 to nail the new issues above). The
>> ftp://ftp.cwru.edu/pub/bash site just has the main 4.3 file and 25
>> separate patches to merge.
>>
>
>   "A downloadable tar file of the current version with all official
> patches applied is available from savannah."
>   
>
> --
> Chris F.A. Johnson, 
>

Re: Bash-4.3 Official Patch 25

[Chet Ramey]

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 
> 
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $ ./bash  
> $  
> GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31)
> 
> $ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello'
> vulnerable
> hello

Since `.' is probably not in your $PATH before /bin, `env' is not running
the patched version.  Try changing `bash -c' to `./bash -c'.

-- 
``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 25

[Greg Wooledge]

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 two-user license
imadev:~$ bash -c 'echo "$BASH_VERSION"'
4.3.25(1)-release
imadev:~$ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

Are you absolutely sure that the "bash" your command is invoking is
the patched one?

Re: Bash-4.3 Official Patch 25

[gnu.bash.bug]

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 and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ./bash  
$  
GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31)

$ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello

Any hints?

Thanks in advance!

Michael

Re: Issues with exported functions

[Chet Ramey]

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, that's one of the approaches under consideration.  It raises the
bar for abuse by requiring that an attacker be able to create environment
variables with arbitrary names as well as values.  It is not,
unfortunately, backwards compatible.

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

[Chet Ramey]

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 sexist stereotype "as an argument". Remove that
> sentence and nothing changes of my argument.

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.

-- 
``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

[Chet Ramey]

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 value begins exactly with the characters
> in question. 

This is correct, but it has rarely (that is to say, never) come up in
practice.

-- 
``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

[Gabriel Corona]

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 user variable:

  foo() {
echo Executing function "$@"
  }

  foo="aa"
  
  export -f foo
  export foo
  
  bash -c foo
  # OK
  
  bash -c 'echo $foo'
  # OK as well
  
  bash -c env
  # In fact the environment variable is set twice, I didn't know it was event 
possible
  
  dash -c 'echo $foo'
  # Dash find the second one: () { echo Executing function "$@" }

The second (more important) point would allow a variable to begin with
"() {}" or similar:

  # I'm not aware of the function export feature
  # or x comes from somewhere else:
  $ x="() {}"  bash -c 'echo $x' 2>/dev/null
  
  $ x="() {}"  dash -c 'echo $x' 2>/dev/null
  () {}

--
Gabriel

Re: Issues with exported functions

[Gabriel Corona]

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 user variable:

  foo() {
echo Executing function "$@"
  }

  foo="aa"
  
  export -f foo
  export foo
  
  bash -c foo
  # OK
  
  bash -c 'echo $foo'
  # OK as well
  
  bash -c env
  # In fact the environment variable is set twice, I didn't know it was event 
possible
  
  dash -c 'echo $foo'
  # Dash find the second one: () { echo Executing function "$@" }

The second (more important) point would allow a variable to begin with
"() {}" or similar:

  $ x="() {}"  bash -c 'echo $x' 2>/dev/null
  
  $ x="() {}"  dash -c 'echo $x' 2>/dev/null
  () {}

--
Gabriel

Re: Issues with exported functions

[lolilolicon]

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 and nothing changes of my argument.

Re: Issues with exported functions

[Pierre Gaston]

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 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 "bug" are the real "perverts".  They expect documented
> >> > behavior to work
> >> > some way other than is documented... How is that not perverted?
> >>
> >> You're arguing "like a girl". I didn't say the documented behavior was a
> >
> >
> > uh?  really?
> > Please go away, it's already bad enough you are discussing things you
> don't
> > fully understand without being sexist on top of that.
>
> Isn't the whole point of discussing better understanding? If you have to
> fully understand a thing to be allowed to discuss it, then there will be
> no discussion allowed.
>
> You're too easily stoked. Please don't be so sensitive. Notice the double
> quotes? I'm using the stereotype as a shorthand. Stereotypes exist and
> are widely understood, much like idioms.
>
> 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.

Re: Issues with exported functions

[lolilolicon]

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 quite the perverts, so...
>> >>
>> >
>> > Personally I find those who don't read the man page, and then claim that
>> > documented
>> > behavior is a "bug" are the real "perverts".  They expect documented
>> > behavior to work
>> > some way other than is documented... How is that not perverted?
>>
>> You're arguing "like a girl". I didn't say the documented behavior was a
>
>
> uh?  really?
> Please go away, it's already bad enough you are discussing things you don't
> fully understand without being sexist on top of that.

Isn't the whole point of discussing better understanding? If you have to
fully understand a thing to be allowed to discuss it, then there will be
no discussion allowed.

You're too easily stoked. Please don't be so sensitive. Notice the double
quotes? I'm using the stereotype as a shorthand. Stereotypes exist and
are widely understood, much like idioms.

In any event, this is but irrelevant to the discussion. Do not seize the
red herring.

Re: Issues with exported functions

[Pierre Gaston]

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't read the man page, and then claim that
> > documented
> > behavior is a "bug" are the real "perverts".  They expect documented
> > behavior to work
> > some way other than is documented... How is that not perverted?
>
> You're arguing "like a girl". I didn't say the documented behavior was a


uh?  really?
Please go away, it's already bad enough you are discussing things you don't
fully understand without being sexist on top of that.

Re: Issues with exported functions

[lolilolicon]

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 "bug" are the real "perverts".  They expect documented
> behavior to work
> some way other than is documented... How is that not perverted?

You're arguing "like a girl". I didn't say the documented behavior was a
bug. By "perverts", I meant "clever, sometimes too clever".

By that "but", I also meant to deliver that my expectation would
probably turn out to be wrong, "because bash programmers".

I don't mean to sound offensive. Please don't take it too heavily.

> I also find redefining functions with every invocation of bash a major waste
> of cpu cycles.
>
> Tons of functions are defined these days with all the support for
> bash completions.

I do not think about optimization. My opinion is the need for the
programmer to think about optimization (that's not relevant to the
problem at hand) is a symptom of bad design (of the language / tool), or
perhaps the programmer is using wrong tool / using the tool wrong.

As to your particular argument for completions: I think zsh optimizes
for this with autoloading mechanism, which is a better design.

> In scripts, I usually define *aliases* (which are processed before
> functions)
>
> If you want to execute commands in a script, you must make sure
> you are executing those commands.   So first, those script better set the
> PATH to a
> standard path.  Any script that doesn't has no right to complain about this
> "bug".
>
> 2nd, how many scripts define utils into vars:
>
> cp=/usr/bin/cp
>
> $cp 
>
> ---
> The safe way to define cmnds which I try to use in most of my scripts is to
> define
> them as ALIASES that get expanded before functions.
>
> Example:
>
> #!bin/bash
>
> function true () { false; }
>
> if true; then echo "true==true"; else echo "true==false" ; fi
>
> # above demonstrates what seems to be the bug (a function overriding a
> command)
> # how it got there, is not entirely relevant
>
> #-- fixed example:
>
> PATH=/sbin:/usr/sbin:/bin:/usr/sbin:$PATH
> shopt -s expand_aliases
> alias true=$(type -P true)
>
> if true; then echo "true2==true2"; else echo "true2==false2" ; fi
>
> 
> The 2nd example works because it defines the PATH and defines an an alias
> expansion that translates to the abs path that the alias was defined with.
>
> If people programmed safely to begin with, this wouldn't have come up as a
> bug, but a feature.

Isn't the mere fact that you have to do this round-around thing to
"program safely" a proof by demonstration that exported functions are
trouble?

>From a theoretical stand point, function export is really a hack. Or a
backdoor as termed by Eric Blake in another thread. When you export a
function, bash really creates and exports a variable,

% bash -c 'fun() { :;}; export -f fun; env -0 | grep -z "^fun="'
fun=() {  :
}

So the token '() {' is the only "protocol" for bash function export /
import. A bit too magic, IMO. And of course it forbids importing normal
variables that match the token.

Re: Issues with exported functions

[Geir Hauge]

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 seems to confirm that:
>
> $ x='() { echo a; }' bash -c 'echo "$x"'
>
> $ x='()  { echo a; }' bash -c 'echo "$x"'
> ()  { echo a; }
>
>
> So is there a way to be able to export variables with arbitrary values,
> including '() {' ?  Sorry if this has been discussed before.
>

There's the -p flag, but it has other side effects

$ x='() { echo a; }' bash -pc 'echo "$x"'
() { echo a; }

I also dislike that it parses exported functions by default; it violates
the "don't treat data as code" rule. Sure would be nice if there was a
separate flag that only disables parsing of exported functions.

-- 
Geir Hauge

Re: Issues with exported functions

[Pierre Gaston]

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 useful.
> >
> > There are more things in heaven and earth that are dreamt of in your
> > philosophy.
>
> OK guys! Exported functions are widely used by experts, I get it now.
>
> >
> >> Otherwise, if this feature is going to stay (can anyone enlighten me why
> >> it's useful?), please document it explicitly.
> >
> > Function export is documented.  The exact mechanism need not be.
>
> Sure, the mechanism need not be documented, if it didn't matter on the
> interface level. But it does. In particular,
>
> % pat='() { $:*;}' bash -c 'tr "$pat" _ <<< "(x){1}"'
> (x){1}
>
> (This is bash 4.3.25)
>
> This is not the best example, but you get the idea.
>
> Perhaps you have plans to change the implementation?
>
>
How many instance have you found since the introduction of this feature
more than 20 years ago?

Re: Issues with exported functions

[Davide Brini]

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 are dreamt of in your
> philosophy.
> 
> > Otherwise, if this feature is going to stay (can anyone enlighten me why
> > it's useful?), please document it explicitly.
> 
> 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 value begins exactly with the characters
in question. A quick test seems to confirm that:

$ x='() { echo a; }' bash -c 'echo "$x"'

$ x='()  { echo a; }' bash -c 'echo "$x"'
()  { echo a; }


So is there a way to be able to export variables with arbitrary values,
including '() {' ?  Sorry if this has been discussed before.

Thanks

-- 
D.

Re: Issues with exported functions

[lolilolicon]

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 of in your
> philosophy.

OK guys! Exported functions are widely used by experts, I get it now.

>
>> Otherwise, if this feature is going to stay (can anyone enlighten me why
>> it's useful?), please document it explicitly.
>
> Function export is documented.  The exact mechanism need not be.

Sure, the mechanism need not be documented, if it didn't matter on the
interface level. But it does. In particular,

% pat='() { $:*;}' bash -c 'tr "$pat" _ <<< "(x){1}"'
(x){1}

(This is bash 4.3.25)

This is not the best example, but you get the idea.

Perhaps you have plans to change the implementation?

Re: Issues with exported functions

[Geir Hauge]

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 has had this feature since "forever"

$ fun='() { echo "$BASH_VERSION";}' bash1 -c fun
1.14.7(1)

Your bash 4.2.43 is no exception, but the way declare's -p and -f
options interact did change in 4.3, so try with just ''declare -f fun''
instead

-- 
Geir Hauge