On 9/27/2014 6:49 PM, Mark Goldfinch wrote:
Hi everyone,
Can someone clarify to me why y.tab.c is included within the bash source
tree if it is generated from parse.y?
Not all platforms have up to date tools for generating y.tab.c from parse.y.
Seeing that it appears likely we're going to e
I was wondering if anybody was going to address the problem with 4.2 patch
49 ?
It is still corrupted on the FTP server. There are a few lines that appear
to have been deleted out of the middle of the patch file.
Not only is there a critical line of code missing, but the the 'patch'
command will
On 09/27/2014 08:50 PM, Chet Ramey wrote:
>BASH PATCH REPORT
>=
> /* Don't import function names that are invalid identifiers from the
>environment, though we still allow them to be defined as shell
>
Hi everyone,
Can someone clarify to me why y.tab.c is included within the bash source
tree if it is generated from parse.y?
If one looks in the FreeBSD ports tree, they're deliberately taking the
initiative to touch parse.y to ensure that y.tab.c is always rebuilt.
Seeing that it appears likely
Chet Ramey wrote on Sat, 27 Sep 2014 22:50:07:
> Bash-Release: 4.3
> Patch-ID: bash43-027
> Bug-Reported-by: Florian Weimer
Excellent.
Thanks for pulling in Florian Weimer's prefix/suffix approach. This is a big
help.
--- David A. Wheeler
BASH PATCH REPORT
=
Bash-Release: 2.05b
Patch-ID: bash205b-010
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported functions
BASH PATCH REPORT
=
Bash-Release: 3.0
Patch-ID: bash30-019
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported functions to
BASH PATCH REPORT
=
Bash-Release: 3.1
Patch-ID: bash31-020
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported functions to
BASH PATCH REPORT
=
Bash-Release: 3.2
Patch-ID: bash32-054
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported functions to
BASH PATCH REPORT
=
Bash-Release: 4.0
Patch-ID: bash40-041
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported functions to
BASH PATCH REPORT
=
Bash-Release: 4.1
Patch-ID: bash41-014
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported funct
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-050
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported funct
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-027
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported funct
On 09/27/2014 07:47 PM, Chet Ramey wrote:
> On 9/27/14, 8:49 PM, Eric Blake wrote:
>> On 09/27/2014 05:59 PM, Chet Ramey wrote:
>>> On 9/27/14, 4:29 PM, Eric Blake wrote:
On 09/27/2014 12:53 PM, Chet Ramey wrote:
>
>>> We have an opportunity to close up a potential problem here, at least
>>>
On 9/27/14, 8:49 PM, Eric Blake wrote:
> On 09/27/2014 05:59 PM, Chet Ramey wrote:
>> On 9/27/14, 4:29 PM, Eric Blake wrote:
>>> On 09/27/2014 12:53 PM, Chet Ramey wrote:
>> We have an opportunity to close up a potential problem here, at least
>> with respect to function names containing `/'.
>
>
On 09/27/2014 05:59 PM, Chet Ramey wrote:
> On 9/27/14, 4:29 PM, Eric Blake wrote:
>> On 09/27/2014 12:53 PM, Chet Ramey wrote:
>
>> Right now, we know of no way for an attacker to force an arbitrary
>> variable name - ONLY arbitrary variable contents.
>
> Sure, but we didn't know that at the t
On 9/27/14, 5:23 PM, Eric Blake wrote:
> It should be fairly easy to validate whether an incoming environment
> name=value pair names a valid shell function name, without having to
> resort to the full power (and possible unknown bugs) of the parser. And
> it is only common sense that we do so.
On Sep 27, 2014, at 6:51 PM, Eric Blake wrote:
> On 09/27/2014 04:21 PM, Chet Ramey 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
>>
>> This is dash's niche.
>
>
On 9/27/14, 4:57 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2014-09-27 22:29 Eric Blake napisał(a):
>> Thankfully, bash already forbids trying to name a function 'a=b'
>
> It works in bash 4.3.26:
>
> $ function a=b() { echo A; }
> $ "a=b"
> A
> $ a\=b
> A
Yeah, and it even attempts to exp
On 9/27/14, 4:29 PM, Eric Blake wrote:
> On 09/27/2014 12:53 PM, Chet Ramey wrote:
> Right now, we know of no way for an attacker to force an arbitrary
> variable name - ONLY arbitrary variable contents.
Sure, but we didn't know that at the time. We still don't, really.
> So I would prefer a
On 9/26/14, 1:06 PM, Alan Wild wrote:
> 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
On 9/26/14, 12:58 PM, 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
> based on code from Chet that just causes bash to reject functions where
> code appears outside of the func
On 09/27/2014 04:21 PM, Chet Ramey wrote:
>> 1) make bash when invoked as /bin/sh fail those bash-isms
>
> It's come up before, and it's not something that bash has ever been
> intended to do. When invoked as /bin/sh, bash will behave as a posix
> superset. Posix allows this.
Even dash is a po
On 9/25/14, 4:05 PM, mich...@moria.de wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i586
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu'
> -DCON
On 9/26/14, 10:51 AM, Steve Simmons wrote:
>
> 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/s
2014-09-27 23:12 Eric Blake napisał(a):
> On 09/27/2014 02:57 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> > 2014-09-27 22:29 Eric Blake napisał(a):
> >> Thankfully, bash already forbids trying to name a function 'a=b'
> >
> > It works in bash 4.3.26:
> >
> > $ function a=b() { echo A; }
> >
On 09/27/2014 03:10 PM, Jay Freeman (saurik) wrote:
> [I am terribly sorry that my In-Reply-To is wrong :/]
>
> - "Eric Blake" wrote:
>
>> ... Remember, the security hole of
>> Shell Shock is NOT what the function is named, but the fact that
>> arbitrary variable contents were being parsed.
On 09/27/2014 02:57 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2014-09-27 22:29 Eric Blake napisał(a):
>> Thankfully, bash already forbids trying to name a function 'a=b'
>
> It works in bash 4.3.26:
>
> $ function a=b() { echo A; }
> $ "a=b"
> A
Oh, you used the 'function' keyword, couple
[I am terribly sorry that my In-Reply-To is wrong :/]
- "Eric Blake" wrote:
> ... Remember, the security hole of
> Shell Shock is NOT what the function is named, but the fact that
> arbitrary variable contents were being parsed. ...
Not quite: the point of exploit can be in the variable nam
On 09/27/2014 02:29 PM, Eric Blake wrote:
> On 09/27/2014 12:53 PM, Chet Ramey wrote:
>
>> $ function /bin/echo () { builtin echo whoops; }
>>
>
>> along with exporting these functions and importing them without complaint.
>>
>> This is obviously bad, and I removed the ability to do this in the f
2014-09-27 22:29 Eric Blake napisał(a):
> Thankfully, bash already forbids trying to name a function 'a=b'
It works in bash 4.3.26:
$ function a=b() { echo A; }
$ "a=b"
A
$ a\=b
A
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
On 09/27/2014 12:53 PM, Chet Ramey wrote:
> $ function /bin/echo () { builtin echo whoops; }
>
> along with exporting these functions and importing them without complaint.
>
> This is obviously bad, and I removed the ability to do this in the first
> patch in the event that someone figured out
On Saturday, September 27, 2014 3:51:23 PM UTC+1, Andreas Schwab wrote:
> becker...@gmail.com writes:
>
>
>
> > $ (env;echo echo 'hello') | bash
>
>
>
> You cannot expect that the output of env is parsable by a shell. First
>
> and foremost, it lacks any kind of quoting.
env may not be th
On 9/27/14, 8:06 AM, David A. Wheeler wrote:
> I agree it would be MUCH better to append () to the "variable" name if it is
> a function export. If that suffix can be included in the official bash
> release, I would be delighted.
>
> There had been earlier claims that () might fail on old syste
On 9/26/14, 4:17 PM, 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
On 9/26/14, 4:43 PM, Brian J. Fox wrote:
>
> 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 h
Eric Blake wrote:
What prevents BASH_FUNC_foo = '(){ :; ...';
Nothing, as you wrote it, because you have no () on the left of the
equal.
Then what is wrong with
foo()={ :; ... ;}... That cannot be a legal variable name either.
Other languages like PERL rely on ENV vars and will fail b
becker...@gmail.com writes:
> $ (env;echo echo 'hello') | bash
You cannot expect that the output of env is parsable by a shell. First
and foremost, it lacks any kind of quoting.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 82
On Sep 27, 2014, at 2:19 AM, Eric Blake wrote:
> The prefix is nice for quick identification, but what is ESSENTIAL is
> something that puts shell functions in a namespace that is untouchable
> by normal shell variables (the "()" suffix in Florian's patch). If all
> you do is add a prefix, but
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACK
I currently have this problem with the latest bash from Arch linux which is
biting my at(1) commands. Exported functions make the environment
non-parseable.
##
robin@bunyip:~
$ export -nf psg hsg #clean out my exported functions
robin
I'm trying to patch Bash 4.2 with the latest patch 049. It appears as if
the patch file itself is corrupted. The corresponding patch 026 for Bash
4.3 is fine.
When running patch with mostly default arguments, it seems to work but has
to use merge fuzzing, which it complains about...
$ patch -p0
Le 27. 09. 14 07:53, Eric Blake a écrit :
[...]
So, to FULLY test whether you are still vulnerable to ShellShock, we
must come up with a test that proves that NO possible function body
assigned to a valid shell variable name can EVER cause bash to invoke
the parser without your consent. For tha
I agree it would be MUCH better to append () to the "variable" name if it is a
function export. If that suffix can be included in the official bash release,
I would be delighted.
There had been earlier claims that () might fail on old systems, but I have not
seen evidence of it. I do not have
On Saturday, September 27, 2014 8:19:49 AM UTC+2, Eric Blake wrote:
>
> I am also in favor of both approaches - moving shell functions into a
> non-colliding namespace (so that arbitrary contents of regular variables
> CANNOT trigger parser bugs) and making shell function exports
> configurable an
45 matches
Mail list logo
