On 4/21/16 3:40 AM, dnade@orange.com wrote:
> I think the shellshock mitigations have blocked the injection from happening.
>
> Do you think these should/could be applied to all function definitions?
That's what the posix-mode behavior of abandoning the entire script does.
--
``The lyf so
Hi
For the record it does not work with "fake" exported functions. I was scared
this could be really bad be so I've tested this case :
Here is inject.py
#!/usr/bin/python -tt
import os
os.putenv('BASH_FUNC_foo%%', '''() { avg=0;
avg=((avg+6));
echo -n "This function was never called. Bash versio
On 4/20/16 8:33 AM, David Maas wrote:
> Incidentally, is it possible that somehow )) is simply interpreted the same
> as } in this situation? It would also explain the perceived behavior.
No. The parser resynchronizes at newline when performing error recovery.
--
``The lyf so short, the craft s
Fair enough.
On Wed, Apr 20, 2016 at 8:44 AM, Greg Wooledge wrote:
> On Wed, Apr 20, 2016 at 08:30:48AM -0700, David Maas wrote:
> > So if you really want my opinion, the shell should be aware that it's in
> a
> > function.
>
> Agreed, unless it's really hard to do.
>
> > You could possibly impl
On Wed, Apr 20, 2016 at 08:30:48AM -0700, David Maas wrote:
> So if you really want my opinion, the shell should be aware that it's in a
> function.
Agreed, unless it's really hard to do.
> You could possibly implement this by keeping track of the parent
> pid.
Nonsense. Function calls do not c
Incidentally, is it possible that somehow )) is simply interpreted the same
as } in this situation? It would also explain the perceived behavior.
On Wed, Apr 20, 2016 at 12:55 AM, konsolebox wrote:
> On Tue, Apr 19, 2016 at 10:45 PM, David Maas wrote:
> > Running the echo and other contents of
So if you really want my opinion, the shell should be aware that it's in a
function. You could possibly implement this by keeping track of the parent
pid. Another solution would be to not check the syntax of the function
until the function is actually run. I wouldn't do strict posix soley
because t
On Tue, Apr 19, 2016 at 10:45 PM, David Maas wrote:
> Running the echo and other contents of the function really doesn't seem like
> the correct behavior. If the function isn't called, then its contents
> shouldn't be executed.
Choose: Should the shell stop execution or not? Can you give a theor
On 4/19/16 7:52 AM, Greg Wooledge wrote:
> On Tue, Apr 19, 2016 at 07:45:27AM -0700, David Maas wrote:
>> Running the echo and other contents of the function really doesn't seem
>> like the correct behavior. If the function isn't called, then its contents
>> shouldn't be executed.
>
> I believe th
On 4/19/16 7:45 AM, David Maas wrote:
> Running the echo and other contents of the function really doesn't seem
> like the correct behavior. If the function isn't called, then its contents
> shouldn't be executed.
There are no `function contents'. There is no function. There was a
syntax error
On 4/18/16 12:52 PM, David Maas wrote:
> Hi! I found a bug in bash, I've checked versions 4.1 (centos 6.7), 4.2
> (centos 7.2), and 4.3.30 (from the ftp site). The bug is that if you do a
> double parenthesis math thing with the wrong syntax, the script runs the
> function during what I assume is s
On Tue, Apr 19, 2016 at 07:45:27AM -0700, David Maas wrote:
> Running the echo and other contents of the function really doesn't seem
> like the correct behavior. If the function isn't called, then its contents
> shouldn't be executed.
I believe the theory is the syntax error is confusing the pars
On Tue, Apr 19, 2016 at 3:52 AM, David Maas wrote:
> Hi! I found a bug in bash, I've checked versions 4.1 (centos 6.7), 4.2
> (centos 7.2), and 4.3.30 (from the ftp site). The bug is that if you do a
> double parenthesis math thing with the wrong syntax, the script runs the
> function during what
13 matches
Mail list logo
