2014-09-30 17:06:22 +0100, Stephane Chazelas:
[...]
> Same with "export -p":
>
> $ env -i $'a\necho test\na=b' ksh -c 'export -p' | ksh
> test
>
> And bash is also vulnerable.
>
> $ env -i $'a\necho test\na=b' bash -c 'export -p'
> declare -x OLDPWD
> declare -x PWD="/home/stephane"
> declare -x
2014-09-30 09:04:28 -0600, Eric Blake:
> On 09/30/2014 08:42 AM, Eric Blake wrote:
> > Thanks; here's another ksh bug:
> >
> > $ env 'a|b=' bash -c 'set | grep a"."b'
> > $ env 'a|b=' ksh -c 'set | grep a"."b'
> > a|b=''
> >
> > But per the documentation of set, "If no options or arguments are
>
On 09/30/2014 08:42 AM, Eric Blake wrote:
> Thanks; here's another ksh bug:
>
> $ env 'a|b=' bash -c 'set | grep a"."b'
> $ env 'a|b=' ksh -c 'set | grep a"."b'
> a|b=''
>
> But per the documentation of set, "If no options or arguments are
> specified, set shall write the names and values of all
On 09/29/2014 08:33 PM, David Korn wrote:
> I fixed the bug in ksh that allows you delete a special builtin.
Thanks; here's another ksh bug:
$ env 'a|b=' bash -c 'set | grep a"."b'
$ env 'a|b=' ksh -c 'set | grep a"."b'
a|b=''
But per the documentation of set, "If no options or arguments are
spe
I fixed the bug in ksh that allows you delete a special builtin.
On Mon, Sep 29, 2014 at 5:25 PM, Dan Douglas wrote:
> Just a few points to add.
>
> On Monday, September 29, 2014 04:29:52 PM Stephane Chazelas wrote:
> > 2014-09-29 09:04:00 -0600, Eric Blake:
> > [...]
> > > > "The function is
On 9/29/14, 5:25 PM, Dan Douglas wrote:
> This doesn't normally matter because POSIX requires special builtins to take
> precedence over functions during command search, so even if you have such a
> function defined it is impossible to call. Bash doesn't use the correct
> search
> order howeve
On Tuesday, September 30, 2014 12:11:15 AM Andreas Schwab wrote:
> Dan Douglas writes:
>
> > Another thing you can do in bash is bypass its command name check by using
> > a
> > null zeroth word.
> >
> > $ { function } { echo test; }; <() }; }
> > test
> >
> > Ordinarily } would be uncallable,
Dan Douglas writes:
> Another thing you can do in bash is bypass its command name check by using a
> null zeroth word.
>
> $ { function } { echo test; }; <() }; }
> test
>
> Ordinarily } would be uncallable,
Only literal } is special, you can use \} instead, or store it in a
variable.
Andreas.
Just a few points to add.
On Monday, September 29, 2014 04:29:52 PM Stephane Chazelas wrote:
> 2014-09-29 09:04:00 -0600, Eric Blake:
> [...]
> > > "The function is named fname; the application shall ensure that it is a
> > > name (see XBD Name) and that it is not the name of a special built-in
u
2014-09-29 09:04:00 -0600, Eric Blake:
[...]
> I would expect something like "It shall be an error if fname is the name
> of a special built-in utility", as _that_ would be a hard requirement on
> bash, not just the application. Maybe we have a bug in the POSIX spec
> for a missing requirement.
[.
2014-09-29 09:04:00 -0600, Eric Blake:
[...]
> > "The function is named fname; the application shall ensure that it is a
> > name (see XBD Name) and that it is not the name of a special built-in
> > utility."
> >
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_
[adding Austin Group]
On 09/28/2014 07:11 PM, Chet Ramey wrote:
> On 9/27/14, 10:03 PM, Eric Blake wrote:
>
>>> Yes, it's an application requirement. Regardless, all the versions of bash
>>> we're talking about here reject non-identifiers.
>>
>> I'm still trying to find that line in the actual P
2014-09-27 23:53:12 +0200, Arfrever Frehtes Taifersar Arahesis:
[...]
> Ability to export/import functions with "=" in function names
> could be achieved by not embedding function names in
> environmental variables and using a single BASH_FUNCTIONS
> environmental variable whose value would contain
On 9/27/14, 10:03 PM, Eric Blake wrote:
>> Yes, it's an application requirement. Regardless, all the versions of bash
>> we're talking about here reject non-identifiers.
>
> I'm still trying to find that line in the actual POSIX spec.
"The function is named fname; the application shall ensure t
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 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
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 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
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
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
- "Á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
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
- "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
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
(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
39 matches
Mail list logo
