Bash-4.3 Official Patch 25

[Chet Ramey]

 BASH PATCH REPORT
 =

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

Bug-Reported-by:Stephane Chazelas 
Bug-Reference-ID:
Bug-Reference-URL:

Bug-Description:

Under certain circumstances, bash will execute user code while processing the
environment for exported function definitions.

Patch (apply with `patch -p0'):

*** ../bash-4.3-patched/builtins/common.h   2013-07-08 16:54:47.0 
-0400
--- builtins/common.h   2014-09-12 14:25:47.0 -0400
***
*** 34,37 
--- 49,54 
  #define SEVAL_PARSEONLY   0x020
  #define SEVAL_NOLONGJMP 0x040
+ #define SEVAL_FUNCDEF 0x080   /* only allow function definitions */
+ #define SEVAL_ONECMD  0x100   /* only allow a single command */
  
  /* Flags for describe_command, shared between type.def and command.def */
*** ../bash-4.3-patched/builtins/evalstring.c   2014-02-11 09:42:10.0 
-0500
--- builtins/evalstring.c   2014-09-14 14:15:13.0 -0400
***
*** 309,312 
--- 313,324 
  struct fd_bitmap *bitmap;
  
+ if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)
+   {
+ internal_warning ("%s: ignoring function definition attempt", 
from_file);
+ should_jump_to_top_level = 0;
+ last_result = last_command_exit_value = EX_BADUSAGE;
+ break;
+   }
+ 
  bitmap = new_fd_bitmap (FD_BITMAP_SIZE);
  begin_unwind_frame ("pe_dispose");
***
*** 369,372 
--- 381,387 
  dispose_fd_bitmap (bitmap);
  discard_unwind_frame ("pe_dispose");
+ 
+ if (flags & SEVAL_ONECMD)
+   break;
}
}
*** ../bash-4.3-patched/variables.c 2014-05-15 08:26:50.0 -0400
--- variables.c 2014-09-14 14:23:35.0 -0400
***
*** 359,369 
  strcpy (temp_string + char_index + 1, string);
  
! if (posixly_correct == 0 || legal_identifier (name))
!   parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
! 
! /* Ancient backwards compatibility.  Old versions of bash exported
!functions like name()=() {...} */
! if (name[char_index - 1] == ')' && name[char_index - 2] == '(')
!   name[char_index - 2] = '\0';
  
  if (temp_var = find_function (name))
--- 364,372 
  strcpy (temp_string + char_index + 1, string);
  
! /* Don't import function names that are invalid identifiers from the
!environment, though we still allow them to be defined as shell
!variables. */
! if (legal_identifier (name))
!   parse_and_execute (temp_string, name, 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
  
  if (temp_var = find_function (name))
***
*** 382,389 
  report_error (_("error importing function definition for `%s'"), 
name);
}
- 
- /* ( */
- if (name[char_index - 1] == ')' && name[char_index - 2] == '\0')
-   name[char_index - 2] = '('; /* ) */
}
  #if defined (ARRAY_VARS)
--- 385,388 
*** ../bash-4.3-patched/subst.c 2014-08-11 11:16:35.0 -0400
--- subst.c 2014-09-12 15:31:04.0 -0400
***
*** 8048,8052 
  goto return0;
}
!   else if (var = find_variable_last_nameref (temp1))
{
  temp = nameref_cell (var);
--- 8118,8124 
  goto return0;
}
!   else if (var && (invisible_p (var) || var_isset (var) == 0))
!   temp = (char *)NULL;
!   else if ((var = find_variable_last_nameref (temp1)) && var_isset (var) 
&& invisible_p (var) == 0)
{
  temp = nameref_cell (var);
*** ../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 24
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 25
  
  #endif /* _PATCHLEVEL_H_ */

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

Re: Bash-4.3 Official Patch 25

[Eric Blake]

On 09/24/2014 08:27 AM, Chet Ramey wrote:
>BASH PATCH REPORT
>=
> 
> Bash-Release: 4.3
> Patch-ID: bash43-025
> 
> Bug-Reported-by:  Stephane Chazelas 
> Bug-Reference-ID:
> Bug-Reference-URL:

https://bugzilla.redhat.com/show_bug.cgi?id=1141597 describes this bug
(aka CVE-2014-6271), and points out that even _with_ this patch, there
is still a flaw that attackers can use to overwrite portions of the
filesystem, which is also a possible exploitation avenue:

$ ls -l date
ls: cannot access date: No such file or directory
$ env -i  X='() { (a)=>\' bash -c 'date'
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ ls -l date
-rw---. 1 taviso taviso 0 Sep 24 14:06 date


> *** 359,369 
> strcpy (temp_string + char_index + 1, string);
>   
> !   if (posixly_correct == 0 || legal_identifier (name))
> ! parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
> ! 
> !   /* Ancient backwards compatibility.  Old versions of bash exported
> !  functions like name()=() {...} */

Personally, I think that exporting functions via names that CANNOT be
valid normal variables, rather than excluding a subset of values to
normal variables that cannot be exported, would be the better course of
action.  It seems quite odd that my choice of whitespace in what I
thought was an arbitrary string assignment to a normal variable will
determine what my child process will see:

$ f='(){ :; }' bash -c 'type f; echo "\"$f\""'
bash: line 0: type: f: not found
"(){ :; }"
$ f='() { :; }' bash -c 'type f; echo "\"$f\""'
f is a function
f ()
{
:
}
""

and I'd feel much more comfortable with exporting f()=... as the
backdoor for passing the function definition, _particularly_ since the
shell already allows functions and variables to co-exist:

$ bash -c 'export f=hello; f() { echo goodbye; }; echo "\"$f\""; f'
"hello"
goodbye

Here's hoping there's more official patches forthcoming.

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



signature.asc
Description: OpenPGP digital signature

Re: Bash-4.3 Official Patch 25

[Ángel González]

Eric Blake wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1141597 describes this bug
> (aka CVE-2014-6271), and points out that even _with_ this patch, there
> is still a flaw that attackers can use to overwrite portions of the
> filesystem, which is also a possible exploitation avenue:
> 
> $ ls -l date
> ls: cannot access date: No such file or directory
> $ env -i  X='() { (a)=>\' bash -c 'date'
> bash: X: line 1: syntax error near unexpected token `='
> bash: X: line 1: `'
> bash: error importing function definition for `X'
> $ ls -l date
> -rw---. 1 taviso taviso 0 Sep 24 14:06 date

It doesn't just create 0-sized files:

$ echo "{ echo 'Hello World' }" > foo.sh

$ VAR='() { (a) =>\' bash foo.sh
bash: VAR: line 1: syntax error near unexpected token `='
bash: VAR: line 1: `'
bash: error importing function definition for `VAR'

$ cat {
Hello World }


OTOH, had we used bash -c foo.sh, it would have removed the script
contents (truncated to 0 bytes).

Re: Bash-4.3 Official Patch 25

[Wesley Hirsch]

Also, you can embed arguments, allowing for arbitrary execution:

$ env -i  X='() { (a)=>\' bash -c 'echo curl -s https://bugzilla.redhat.com/';
head echo
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
http://www.w3.org/TR/html4/loose.dtd";>

  
Red Hat Bugzilla Main Page




  

On Wed, Sep 24, 2014 at 6:44 PM, Ángel González  wrote:

> Eric Blake wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1141597 describes this bug
> > (aka CVE-2014-6271), and points out that even _with_ this patch, there
> > is still a flaw that attackers can use to overwrite portions of the
> > filesystem, which is also a possible exploitation avenue:
> >
> > $ ls -l date
> > ls: cannot access date: No such file or directory
> > $ env -i  X='() { (a)=>\' bash -c 'date'
> > bash: X: line 1: syntax error near unexpected token `='
> > bash: X: line 1: `'
> > bash: error importing function definition for `X'
> > $ ls -l date
> > -rw---. 1 taviso taviso 0 Sep 24 14:06 date
>
> It doesn't just create 0-sized files:
>
> $ echo "{ echo 'Hello World' }" > foo.sh
>
> $ VAR='() { (a) =>\' bash foo.sh
> bash: VAR: line 1: syntax error near unexpected token `='
> bash: VAR: line 1: `'
> bash: error importing function definition for `VAR'
>
> $ cat {
> Hello World }
>
>
> OTOH, had we used bash -c foo.sh, it would have removed the script
> contents (truncated to 0 bytes).
>
>
>

Re: Bash-4.3 Official Patch 25

[mark]

>Bash-Release:4.3
>Patch-ID:bash43-025

As a binary distribution archive maintainer, I'd be keen to see the authors 
distributing a cumulative bash-4.3p025.tar.gz source bundle (probably p026 to 
nail the new issues above). The ftp://ftp.cwru.edu/pub/bash site just has the 
main 4.3 file and 25 separate patches to merge.

ta++

Re: Bash-4.3 Official Patch 25

[Chris F.A. Johnson]

On Wed, 24 Sep 2014, m...@ibiblio.org wrote:




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


As a binary distribution archive maintainer, I'd be keen to see the
authors distributing a cumulative bash-4.3p025.tar.gz source bundle
(probably p026 to nail the new issues above). The
ftp://ftp.cwru.edu/pub/bash site just has the main 4.3 file and 25
separate patches to merge.


  "A downloadable tar file of the current version with all official patches applied 
is available from savannah."
  

--
Chris F.A. Johnson, 

Re: Bash-4.3 Official Patch 25

[gnu.bash.bug]

Hi,

This patch does not seem to work on HP-UX:

$ ./bash --version
GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ./bash  
$  
GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31)

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

Any hints?

Thanks in advance!

Michael

Re: Bash-4.3 Official Patch 25

[Greg Wooledge]

On Thu, Sep 25, 2014 at 06:02:11AM -0700, gnu.bash.bug wrote:
> Hi,
> 
> This patch does not seem to work on HP-UX:

Worked for me on 10.20.

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

imadev:~$ uname -a
HP-UX imadev B.10.20 A 9000/785 2008897791 two-user license
imadev:~$ bash -c 'echo "$BASH_VERSION"'
4.3.25(1)-release
imadev:~$ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

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

Re: Bash-4.3 Official Patch 25

[Chet Ramey]

On 9/25/14, 9:02 AM, gnu.bash.bug wrote:
> Hi,
> 
> This patch does not seem to work on HP-UX:
> 
> $ ./bash --version
> GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31)
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $ ./bash  
> $  
> GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31)
> 
> $ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello'
> vulnerable
> hello

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

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

Re: Bash-4.3 Official Patch 25

[Mark Ashley]

Ah great, thanks for that...though since there's still the bug in p025 (see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 ) I'll keep
spinning my wheels and watching the git branches until p026 rolls out.

ta,
Mark

On Thu, Sep 25, 2014 at 3:55 PM, Chris F.A. Johnson 
wrote:

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

Re: Bash-4.3 Official Patch 25

[Chet Ramey]

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

This is an unrelated problem -- I can get to it via a different code
path -- with a simple fix.  I've attached it.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-20140912/parse.y	2014-08-26 15:09:42.0 -0400
--- parse.y	2014-09-24 22:47:28.0 -0400
***
*** 2959,2962 
--- 2959,2964 
word_desc_to_read = (WORD_DESC *)NULL;
  
+   eol_ungetc_lookahead = 0;
+ 
current_token = '\n';		/* XXX */
last_read_token = '\n';

Re: Bash-4.3 Official Patch 25

[M1ch34lk]

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

You are right! I had like 4 other bash versions in my PATH

So case closed... ;)

Thanks!

Michael

Re: Bash-4.3 Official Patch 25

[Jason Vas Dias]

Good day Chet, bash-list -

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

But now there is an issue - bash seems to lose its idea of stdout / stderr being
a terminal within read loops, as illustrated by this test script (/tmp/t.sh):


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


Its output illustrates the problem:


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


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

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

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

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

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

Its output under Ubuntu bash:

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

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

Thanks & Regards,
Jason



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

Re: Bash-4.3 Official Patch 25

[Greg Wooledge]

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

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

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

Re: Bash-4.3 Official Patch 25

[Andreas Schwab]

Jason Vas Dias  writes:

> 
> #!/bin/bash
>  tty
> echo $'1\n2' > test.list;
> while read line; do
> tty;
> done < test.list
> 
>
> Its output illustrates the problem:
>
> 
> $ ./bash /tmp/t.sh
> /dev/pts/6
> not a tty
> not a tty
> 

tty uses stdin, so this is the expected output.  Why do you think this
has anything to do with this patch?

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

Andreas.

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

Re: Bash-4.3 Official Patch 25

[Jason Vas Dias]

Oops, sorry, this issue is nothing to do with the  bash43-025 patch -
I just verified that the same issue occurs with bash 4.1.2(1) .
The issue was that a script that does an 'stty' command was
failing when run in a 'while read ... ' loop. It wasn't using
'stty -F', so was trying to stty on stdin, which was the list file.
Sorry, my mistake - a nasty coincindence that it was the first
thing I tried with the new bash version.
Regards,
Jason

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

Re: Bash-4.3 Official Patch 25

[Chet Ramey]

On 9/24/14, 5:38 PM, Eric Blake wrote:

> and I'd feel much more comfortable with exporting f()=... as the
> backdoor for passing the function definition, _particularly_ since the
> shell already allows functions and variables to co-exist:

We used to do that, and part of the code that I removed in patch 25
supported the original `name()=() {'.  We didn't use that very long; it
turns out that the Bourne shell (and others, at that time) dumps core on
malformed environment variable names.  It's why we stuck with shell
identifiers, though the check for that didn't come in until later.

I'd be willing to bet that the Bourne shell that still runs on Solaris,
AIX, HP-UX, and SCO (if anyone still runs that) has this problem.
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Bash-4.3 Official Patch 25

[Eric Blake]

On 09/25/2014 05:58 PM, Chet Ramey wrote:
> On 9/24/14, 5:38 PM, Eric Blake wrote:
> 
>> and I'd feel much more comfortable with exporting f()=... as the
>> backdoor for passing the function definition, _particularly_ since the
>> shell already allows functions and variables to co-exist:
> 
> We used to do that, and part of the code that I removed in patch 25
> supported the original `name()=() {'.  We didn't use that very long; it
> turns out that the Bourne shell (and others, at that time) dumps core on
> malformed environment variable names.  It's why we stuck with shell
> identifiers, though the check for that didn't come in until later.
> 
> I'd be willing to bet that the Bourne shell that still runs on Solaris,
> AIX, HP-UX, and SCO (if anyone still runs that) has this problem.

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

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

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

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



signature.asc
Description: OpenPGP digital signature

Re: Bash-4.3 Official Patch 25

[mark]

On Friday, September 26, 2014 9:58:56 AM UTC+10, Chet Ramey wrote:
> On 9/24/14, 5:38 PM, Eric Blake wrote:
> 
> 
> 
> > and I'd feel much more comfortable with exporting f()=... as the
> 
> > backdoor for passing the function definition, _particularly_ since the
> 
> > shell already allows functions and variables to co-exist:
> 
> 
> 
> We used to do that, and part of the code that I removed in patch 25
> 
> supported the original `name()=() {'.  We didn't use that very long; it
> 
> turns out that the Bourne shell (and others, at that time) dumps core on
> 
> malformed environment variable names.  It's why we stuck with shell
> 
> identifiers, though the check for that didn't come in until later.
> 
> 
> 
> I'd be willing to bet that the Bourne shell that still runs on Solaris,
> 
> AIX, HP-UX, and SCO (if anyone still runs that) has this problem.
> 
> -- 
> 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> 
>``Ars longa, vita brevis'' - Hippocrates
> 
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/


Not these Solaris ones :)


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

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

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

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

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

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

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

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

[ralf . naegele]

Hello,

I've downloaded the source for bash 4.3 and all patches, patched the source to 
Patch 25. 
But according some description I've found (http://heise.de/-2403305 sorry, only 
in German
available), you can test with the command

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

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

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

With kind regards,
Ralf

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

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

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

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

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

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

[Greg Wooledge]

On Thu, Sep 25, 2014 at 05:33:38PM +0200, ralf.naeg...@she.net wrote:
> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Did you *install* the patched version so that it is the first "bash" in
your PATH before running this?  If not, you should specify a path to
bash (e.g. ./bash -c "echo ...").

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

[Eric Blake]

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

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

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

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

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



signature.asc
Description: OpenPGP digital signature

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

[Eduardo A . Bustamante López]

On Thu, Sep 25, 2014 at 05:33:38PM +0200, ralf.naeg...@she.net wrote:
> Hello,
> 
> I've downloaded the source for bash 4.3 and all patches, patched the source 
> to Patch 25. 
> But according some description I've found (http://heise.de/-2403305 sorry, 
> only in German
> available), you can test with the command
> 
> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Did you install the patched bash properly? If you forgot to install
it, calling 'bash' will launch the still vulnerable version.

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

[Ralf Naegele]

Hello Eduardo,

I haven't installed the patched bash yet. I called it in the source 
directory after compiling, it with ./bash so I think this should start the 
patched bash. 

Regards,
Ralf



On Thu, 25 Sep 2014, Eduardo A. Bustamante López wrote:

> Date: Thu, 25 Sep 2014 13:50:00 -0700
> From: Eduardo A. Bustamante López 
> To: ralf.naeg...@she.net
> Cc: bug-bash@gnu.org
> Subject: Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)
> 
> On Thu, Sep 25, 2014 at 05:33:38PM +0200, ralf.naeg...@she.net wrote:
> > Hello,
> > 
> > I've downloaded the source for bash 4.3 and all patches, patched the source 
> > to Patch 25. 
> > But according some description I've found (http://heise.de/-2403305 sorry, 
> > only in German
> > available), you can test with the command
> > 
> > env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
>
> Did you install the patched bash properly? If you forgot to install
> it, calling 'bash' will launch the still vulnerable version.
> 

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

[Alexandre FERRIEUX - SOFT/LAN]

On 26/09/2014 08:23, Ralf Naegele wrote:

Hello Eduardo,

I haven't installed the patched bash yet. I called it in the source
directory after compiling, it with ./bash so I think this should start the
patched bash.


You started ./bash as the parent reading the offending line, but did you also 
modify it so that ./bash appears inside ?

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


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

-Alex

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

[Ralf Naegele]

Hello Greg,

thanks for the hint, this seems to be the solution. I've copied the  
compiled bash binary to the first directory from $PATH output and now the 
test is ok:

[naegele@pinie ~]$ env x='() { :;}; echo vulnerable' bash -c "echo this is a 
test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Regards,
Ralf

On Thu, 25 Sep 2014, Greg Wooledge wrote:

> Date: Thu, 25 Sep 2014 16:52:19 -0400
> From: Greg Wooledge 
> To: ralf.naeg...@she.net
> Cc: bug-bash@gnu.org
> Subject: Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)
> 
> On Thu, Sep 25, 2014 at 05:33:38PM +0200, ralf.naeg...@she.net wrote:
> > env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
> 
> Did you *install* the patched version so that it is the first "bash" in
> your PATH before running this?  If not, you should specify a path to
> bash (e.g. ./bash -c "echo ...").
> 

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

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