Re: First security bug related to f-strings

2016-11-05 Thread eryk sun
On Sat, Nov 5, 2016 at 6:50 PM, Irmen de Jong  wrote:
> Perhaps. But in those cases you could just leave things on the default.
> If you choose to run the interpreter with eval (and exec) disabled, you 
> should be aware
> that you'll break tools like that. But for other situations (web server etc) 
> it could
> still be useful? I do agree that not being able to use namedtuple (and 
> perhaps other
> things from the stdlib) is a problem then.

Breaking importlib at startup is not an option. An application would
need to import everything before disabling exec.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: First security bug related to f-strings

2016-11-05 Thread Irmen de Jong
On 5-11-2016 19:08, eryk sun wrote:
> On Sat, Nov 5, 2016 at 5:33 PM, Irmen de Jong  wrote:
>> I think perhaps we should have a command line option / environment variable 
>> to be able
>> to disable 'eval' altogether
> 
> I don't think that's practical. exec and eval are commonly used by
> shells and IDEs such as IDLE and IPython. In the standard library,
> importlib and namedtuple are two important users of exec. Just try
> `import builtins; del builtins.exec, builtins.eval`.
> 

Perhaps. But in those cases you could just leave things on the default.
If you choose to run the interpreter with eval (and exec) disabled, you should 
be aware
that you'll break tools like that. But for other situations (web server etc) it 
could
still be useful? I do agree that not being able to use namedtuple (and perhaps 
other
things from the stdlib) is a problem then.


It was just a thought

Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: First security bug related to f-strings

2016-11-05 Thread eryk sun
On Sat, Nov 5, 2016 at 5:33 PM, Irmen de Jong  wrote:
> I think perhaps we should have a command line option / environment variable 
> to be able
> to disable 'eval' altogether

I don't think that's practical. exec and eval are commonly used by
shells and IDEs such as IDLE and IPython. In the standard library,
importlib and namedtuple are two important users of exec. Just try
`import builtins; del builtins.exec, builtins.eval`.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: First security bug related to f-strings

2016-11-05 Thread Irmen de Jong
On 5-11-2016 18:12, Steve D'Aprano wrote:
> Well, that didn't take very long at all.
> 
> Here's the first security bug which is related to the new (and badly
> misnamed) f-string feature:
> 
> http://bugs.python.org/issue28563


I think perhaps we should have a command line option / environment variable to 
be able
to disable 'eval' altogether

Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list


First security bug related to f-strings

2016-11-05 Thread Steve D'Aprano
Well, that didn't take very long at all.

Here's the first security bug which is related to the new (and badly
misnamed) f-string feature:

http://bugs.python.org/issue28563

Note what I'm not saying: I'm not saying that the bug is *caused* by
f-strings. It is not. The bug is actually caused by the inappropriate use
of eval. But the worrying thing here is:


Bonus: With the new string interpolation in Python 3.7, exploiting 
gettext.c2py becomes trivial:

   gettext.c2py('f"{os.system(\'sh\')}"')(0)

The tokenizer will recognize the entire format-string as just a string,
thus bypassing the security checks.


Yay for hiding arbitrary code evaluation inside something that pretends to
be a string!

My guess is that there is probably more code out there in the wild which is
vulnerable to code injection attacks thanks to the use of eval or exec, but
its been too hard to exploit up until now. But with f-strings, chances are
that they too will be trivially exploitable.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list