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 PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-048
Bug-Reported-by:Stephane Chazelas stephane.chaze...@gmail.com
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances,
BASH PATCH REPORT
=
Bash-Release: 4.1
Patch-ID: bash41-012
Bug-Reported-by:Stephane Chazelas stephane.chaze...@gmail.com
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances,
BASH PATCH REPORT
=
Bash-Release: 4.0
Patch-ID: bash40-039
Bug-Reported-by:Stephane Chazelas stephane.chaze...@gmail.com
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances,
BASH PATCH REPORT
=
Bash-Release: 3.2
Patch-ID: bash32-052
Bug-Reported-by:Stephane Chazelas stephane.chaze...@gmail.com
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash
BASH PATCH REPORT
=
Bash-Release: 3.0
Patch-ID: bash30-017
Bug-Reported-by:Stephane Chazelas stephane.chaze...@gmail.com
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash
BASH PATCH REPORT
=
Bash-Release: 3.1
Patch-ID: bash31-018
Bug-Reported-by:Stephane Chazelas stephane.chaze...@gmail.com
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash
Obviously, the newly disclosed CVE-2014-6271 is pretty bad.
It's been patched now, but I think it's worthwhile to further discuss
how exported functions are implemented in bash.
I'm no bash expert: before today I didn't even realize bash functions
can be exported. And I certainly wouldn't expect
On Thu, Sep 25, 2014 at 03:44:23AM +0800, lolilolicon wrote:
Otherwise, if this feature is going to stay (can anyone enlighten me why
it's useful?), please document it explicitly.
First, it is documented:
Functions may be exported so that subshells automatically have them
defined
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;}' ...
On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge wool...@eeg.ccf.org wrote:
On Thu, Sep 25, 2014 at 03:44:23AM +0800, lolilolicon wrote:
Otherwise, if this feature is going to stay (can anyone enlighten me why
it's useful?), please document it explicitly.
First, it is documented:
On Thu, Sep 25, 2014 at 03:54:19AM +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;}' ...
I'm still waiting for someone to
On 9/24/14, 4:07 PM, Greg Wooledge wrote:
On Thu, Sep 25, 2014 at 03:54:19AM +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='() {
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:
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
lolilolicon wrote:
I don't expect more than a dozen who rely on this... but bash
programmers can be quite the perverts, so...
Personally I find those who don't read the man page, and then claim that
documented
behavior is a bug are the real perverts. They expect documented
behavior to work
On Sep 24, 2014, at 4:06 PM, lolilolicon loliloli...@gmail.com wrote:
On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge wool...@eeg.ccf.org wrote:
So, if Chet removes the feature, it would probably break something that
someone cares about. Maybe there could be a compile-time option to
On 9/24/14, 3:44 PM, lolilolicon wrote:
Personally, I have never needed this feature. I would vote for its
removal: It's very surprising, creates bugs, and is not very useful.
There are more things in heaven and earth that are dreamt of in your
philosophy.
Otherwise, if this feature is going
lolilolicon wrote:
Obviously, the newly disclosed CVE-2014-6271 is pretty bad.
It's been patched now, but I think it's worthwhile to further discuss
how exported functions are implemented in bash.
I'm no bash expert: before today I didn't even realize bash functions
can be exported. And I
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
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
I caught the newsflash at Reuters earlier todat and a
search found the other URLs below. This seemed the only
relevant bash group available for subscription at the
eternal-september NNTP server.
Articles:
New 'Bash' software bug may pose bigger threat than 'Heartbleed'
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
23 matches
Mail list logo
