Python security problem

[Jeroen Demeyer]

I found at least one place where Sage bug #13579 affects the Python
testsuite. If good_user runs the Python testsuite, then evil_user can
force good_user to run arbitraty code.

This might have even more serious consequences, details later...

[Robert Bradshaw]

This isn't just Python, it's a general issue of letting your import
(including dynamic linking in C) paths be in control of a malicious
user, or executing anything in world-writeable directories in general.
Executing stuff from /tmp as part of doctesting bad, glad you caught
it.

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To post to this group, send email to sage-...@googlegroups.com.
> To unsubscribe from this group, send email to sage-devel+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>

[Jeroen Demeyer]

On 2012-10-11 20:54, Robert Bradshaw wrote:
> This isn't just Python, it's a general issue of letting your import
> (including dynamic linking in C) paths be in control of a malicious
> user, or executing anything in world-writeable directories in general.

I actually do think it is "just Python", which is very insecure *by
default*. Of course one can always mess up, but /tmp is not going to
magically end up in $LD_LIBRARY_PATH by itself. In Python, /tmp might
end up in sys.path by itself.

[Volker Braun]

As I wrote on the trac ticket before, there is virtually no difference between "source foobar" in the shell and "import foobar" in Python, both will happily pull in somebody else's code. And nobody would dream of compiling a shared library into /tmp and then set LD_LIBRARY_PATH=/tmp to load it (in fact this might happen behind the scenes if you were to use libtool to compile something in /tmp). I don't see whats different if you put a Python script in /tmp, thats just ill-advised. 

That the Python testsuite does exactly this is a serious mistake.

[Jeroen Demeyer]

On 2012-10-11 21:24, Volker Braun wrote:
> As I wrote on the trac ticket before, there is virtually no difference
> between "source foobar" in the shell and "import foobar" in Python, both
> will happily pull in somebody else's code. And nobody would dream of
> compiling a shared library into /tmp and then set LD_LIBRARY_PATH=/tmp
> to load it (in fact this might happen behind the scenes if you were to
> use libtool to compile something in /tmp). I don't see whats different
> if you put a Python script in /tmp, thats just ill-advised.

As I already said, I do think that Python is to blame here because doing

import some_module

is an absolutely normal Python construct. There is even no easy way to
specify an absolute file path for "some_module". In bash, people are
not normally going to do

source some_file_not_under_my_control.sh

(I would *always* specify a path for "source").

[Robert Bradshaw]

On Thu, Oct 11, 2012 at 12:29 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> On 2012-10-11 21:24, Volker Braun wrote:
>> As I wrote on the trac ticket before, there is virtually no difference
>> between "source foobar" in the shell and "import foobar" in Python, both
>> will happily pull in somebody else's code. And nobody would dream of
>> compiling a shared library into /tmp and then set LD_LIBRARY_PATH=/tmp
>> to load it (in fact this might happen behind the scenes if you were to
>> use libtool to compile something in /tmp). I don't see whats different
>> if you put a Python script in /tmp, thats just ill-advised.
>
> As I already said, I do think that Python is to blame here because doing
>
> import some_module
>
> is an absolutely normal Python construct.

But putting Python files in /tmp and running them is not a normal
thing to do, any more than compiling shared libraries in /tmp. BTW,
it's not the Python testsuite that puts files here, it's us, which
should be fixed by #12415 (which is a much bigger issue).

> There is even no easy way to
> specify an absolute file path for "some_module". In bash, people are
> not normally going to do
>
> source some_file_not_under_my_control.sh
>
> (I would *always* specify a path for "source").

I've seen "source sibling_file" and "source
$path_of_this_file/sibling_file many times, how else are you going to
split functionality across multiple bash scripts? Such scripts
obviously shouldn't be executed from, e.g., /tmp.

- Robert

[Jeroen Demeyer]

On 2012-10-11 21:37, Robert Bradshaw wrote:
> it's not the Python testsuite that puts files here, it's us, which
> should be fixed by #12415 (which is a much bigger issue).

No, it *is* absolutely the upstream Python test suite which is vulnerable.

[Jeroen Demeyer]

On 2012-10-11 21:37, Robert Bradshaw wrote:

> I've seen "source sibling_file" and "source
> $path_of_this_file/sibling_file many times, how else are you going to
> split functionality across multiple bash scripts? Such scripts
> obviously shouldn't be executed from, e.g., /tmp.

The difference is that these "sibling" scripts are created by the user
running the script, i.e. they already exist. That's not insecure. This
is different from the Python situation.

[Robert Bradshaw]

Then *that* should be fixed, not import behavior. Can you send me a pointer?

- Robert

[Robert Bradshaw]

If one can create files in the parent directory, one can (usually?)
rename/replace these sibling scripts.

- Robert

[Jeroen Demeyer]

On 2012-10-11 21:43, Robert Bradshaw wrote:
> If one can create files in the parent directory, one can (usually?)
> rename/replace these sibling scripts.

Not in /tmp (which has the sticky bit set).

[Jeroen Demeyer]

You may all be in denial, but I'm currently preparing a report for
upstream, I'll keep you updated.

[Jeroen Demeyer]

Details are at this upstream report:
http://bugs.python.org/issue16202

[Robert Bradshaw]

I'm happy to be corrected. (I don't think things like permissions and
whether a directory is "safe" should be, in as much as it is possible,
part of a language spec however.)

- Robert

[Jeroen Demeyer]

On 2012-10-11 22:14, Robert Bradshaw wrote:
> I don't think things like permissions and
> whether a directory is "safe" should be, in as much as it is possible,
> part of a language spec however.

That's quite true. However, the alternative of completely changing the
spec would break so much that it's not a good idea (or maybe for Python
4?...). I believe that my patch breaks very little existing code while
still being secure by default. So I think it's the optimal middle ground.

Jeroen.

[Robert Bradshaw]

We'll see what the response is.

I would still argue the bug is in distutils.util.byte_compile for
executing python files in /tmp.

- Robert

[Volker Braun]

On Thursday, October 11, 2012 8:41:57 PM UTC+1, Jeroen Demeyer wrote:

The difference is that these "sibling" scripts are created by the user
running the script, i.e. they already exist.  That's not insecure.  This
is different from the Python situation.

Bash "source" will search in the $PATH and may or may not try cwd (depending on whether bash is in posix mode). Its not just to include files created by the user running the original script.