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://ft
>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.
I caught the newsflash at Reuters earlier todat and a
search found the other URLs below. This seemed the only
relevant bash group available for subscription at the
eternal-september NNTP server.
Articles:
New 'Bash' software bug may pose bigger threat than 'Heartbleed'
http://www.reuters.com/art
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/
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 certa
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 goi
On Sep 24, 2014, at 4:06 PM, lolilolicon wrote:
> On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge 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
>> disable it. Maybe there already is --
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 w
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:
>
>
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.c
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 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 Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge 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:
>
> Functions may be
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 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
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
BASH PATCH REPORT
=
Bash-Release: 3.1
Patch-ID: bash31-018
Bug-Reported-by:Stephane Chazelas
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash will execute user code while pr
BASH PATCH REPORT
=
Bash-Release: 3.0
Patch-ID: bash30-017
Bug-Reported-by:Stephane Chazelas
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash will execute user code while pr
BASH PATCH REPORT
=
Bash-Release: 3.2
Patch-ID: bash32-052
Bug-Reported-by:Stephane Chazelas
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash will execute user code while pr
BASH PATCH REPORT
=
Bash-Release: 4.0
Patch-ID: bash40-039
Bug-Reported-by:Stephane Chazelas
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash will execute user code
BASH PATCH REPORT
=
Bash-Release: 4.1
Patch-ID: bash41-012
Bug-Reported-by:Stephane Chazelas
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash will execute user code
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-048
Bug-Reported-by:Stephane Chazelas
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
Under certain circumstances, bash will execute user code
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
23 matches
Mail list logo
