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:
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
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
Hello,
In the wake of the exported func bug, as can be seen in the nearby thread
Issues with exported functions, many people are just now discovering a host
of things that bash does, of course in a documented way, but that they never
needed in the first place.
Of course, their intention is
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
Eric Blake ebl...@redhat.com 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.
On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh b...@tlinx.org 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
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 Ferrieux alexandre.ferri...@gmail.com 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
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
In article camtvo_osyn6g0d1vnbw1ohpr8w9wg80cpoaegfbkybudzkg...@mail.gmail.com,
lolilolicon loliloli...@gmail.com 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
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
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
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
Johan Nestaas johannest...@gmail.com 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
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
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
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
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 variable...
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 programs are
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
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
pulling
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 EOF test.sh
#!/bin/bash
cat /dev/null
EOF
$ chmod a+x
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.
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
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
On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote:
Alexandre Ferrieux alexandre.ferri...@gmail.com 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
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-standard
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-026
Bug-Reported-by:Tavis Ormandy tav...@cmpxchg8b.com
Bug-Reference-ID:
Bug-Reference-URL: http://twitter.com/taviso/statuses/514887394294652929
BASH PATCH REPORT
=
Bash-Release: 4.0
Patch-ID: bash40-040
Bug-Reported-by:Tavis Ormandy tav...@cmpxchg8b.com
Bug-Reference-ID:
Bug-Reference-URL: http://twitter.com/taviso/statuses/514887394294652929
BASH PATCH REPORT
=
Bash-Release: 2.05b
Patch-ID: bash205b-008
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: 2.05b
Patch-ID: bash205b-009
Bug-Reported-by:Tavis Ormandy tav...@cmpxchg8b.com
Bug-Reference-ID:
Bug-Reference-URL: http://twitter.com/taviso/statuses/514887394294652929
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
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
- Ángel González an...@16bits.net 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:
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 _contents_ of
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
[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
38 matches
Mail list logo
