Sage doctesting on shared systems insecure (#13579)

[Jeroen Demeyer]

Volker Braun discovered a serious security vulnerability in Sage when
doctesting sage/tests/cmdline.py

Until this is fixed, *do not run Sage doctests on shared systems*.
Doctesting individual files, different from sage/tests/cmdline.py should
still be okay.


ISSUE:

The problem is really due to a bad Python design decision (this should
be and will be reported upstream): when running a script like

$ python /path/to/script.py

then /path/to is added in front of sys.path, so any

$ import some_module

statement in /path/to/script.py will /first/ look in the directory
/path/to for some_module. This is problematic if the script lives in
/tmp because any user can put files there. Python does not check for
this. It happens that sage/tests/cmdline.py does create a Sage script
in /tmp, exposing this vulnerability.


WHAT TO DO NOW:

* if you're a Sage user: go ahead as usual. As long as you don't
doctest the Sage library, you should be safe.

* if you're a Sage developer: unless nobody else can log in to your
system, do not run anything like "make ptestlong" or "./sage -t
devel/sage/sage". Consider deleting sage/tests/cmdline.py from your
Sage installation.

* if you're a sysadmin: run the following script to temporarily prevent
this hole from being exploited on your system:
http://boxen.math.washington.edu/home/jdemeyer/plug13579.sh
(this writes some files in /tmp so be careful when /tmp is cleaned
either by a tmp-cleaner or on system startup)


All credit to Volker Braun for discovering this issue!

See also http://trac.sagemath.org/sage_trac/ticket/13579

[Nicolas M. Thiery]

On Wed, Oct 10, 2012 at 10:45:50AM +0200, Jeroen Demeyer wrote:
> Volker Braun discovered a serious security vulnerability in Sage when
> doctesting sage/tests/cmdline.py

Yikes! Good job Volker detecting this!

> * if you're a Sage developer: unless nobody else can log in to your
> system, do not run anything like "make ptestlong" or "./sage -t
> devel/sage/sage". Consider deleting sage/tests/cmdline.py from your
> Sage installation.

Note for the users of the Sage-Combinat queue: I have just inserted a
temporary patch at the bottom of the queue that adds "nodoctest" to
this file, effectively disabling its testing. So you need not worry
about this issue (well, except that any test failure in cmdline.py
that our patches may cause will get unnoticed until the issue is
fixed).

Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[John Cremona]

Would it not be a good idea to disable testing this file (or the bad
part in it) until this has been fixed? In all future testing &
development releases?

John

> Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
> http://Nicolas.Thiery.name/
>
> --
> 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-10 13:59, John Cremona wrote:
> Would it not be a good idea to disable testing this file (or the bad
> part in it) until this has been fixed? In all future testing &
> development releases?

The idea is *not* to do any further releases until this gets sorted out.

[Maarten Derickx]

Maybe it can be fixed by using:

from __future__ import absolute_import

I at least know that python 3 fixed some issues caused by relative imports. But I'm not 100% sure if this problem is also solved.

[Jeroen Demeyer]

On 2012-10-11 00:40, Maarten Derickx wrote:
> Maybe it can be fixed by using:
>
> from __future__ import absolute_import
>
> I at least know that python 3 fixed some issues caused by relative
> imports. But I'm not 100% sure if this problem is also solved.

I think "relative" imports means something different here. It means
relative in the logical module hierarchy, unrelated to the on-disk
structure.

[Nils Bruin]

On Oct 11, 12:27 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> I think "relative" imports means something different here.  It means
> relative in the logical module hierarchy, unrelated to the on-disk
> structure.

A bit of googling to provide context:

Python bug http://bugs.python.org/issue946373 closed as "won't fix" is
about this issue. The comments deal more with the inconvenience of
shadowing library module names than the security implications.

Here's a security warning for emacs about the same issue:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3949

I'm not sure how easy/appropriate the emacs solution is for sage.

[Jeroen Demeyer]

On 2012-10-11 18:22, Nils Bruin wrote:
> Python bug http://bugs.python.org/issue946373 closed as "won't fix" is
> about this issue. The comments deal more with the inconvenience of
> shadowing library module names than the security implications.

Indeed, I don't see any mention of security consequences.