[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
Date: Thu, 05 Jun 2008 01:29:04 -0700
From: Ned Ludd <solar@...too.org>
To: Robert Buchholz <rbu@...too.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: Python Unsafe Module Loading
On Thu, 2008-06-05 at 10:10 +0200, Robert Buchholz wrote:
> On Wednesday 04 June 2008, Ned Ludd wrote:
> > So for nearly every python based program you can simply dump *.so
> > *.py *.pyc files just about anywhere on the file system where an
> > admin might invoke python.
>
> As I also pointed out in our bug [1], this only happens in two cases:
> (1) The interactive shell is used to run python code.
> (2) A python script resides inside an untrusted directory.
>
> What I expect to be the most common use case, running python code
> from /usr, or /home, is safe. Since all out-of-the-box software would
> be installed in directories that are not world-writable, I am tempted
> call (2) an error on the user side. Changing the behaviour of python in
> this manner would also break existing programs.
>
>
> Robert
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=224925
>
Re: (1)
How this limited to interactive shells? Our portage/emerge being
directly not vuln is left to near sheer luck that Nick.C opted to shove
a path into our portage module a-long time ago.. But our tools are
questionable as it all depends on load order..
More examples:
solar@...ia /tmp $ touch re.so
solar@...ia /tmp $ cat foo.py
import string
print "foo"
solar@...ia /tmp $ python foo.py
Traceback (most recent call last):
File "foo.py", line 1, in ?
import string
File "/usr/lib/python2.4/string.py", line 83, in ?
import re as _re
ImportError: /tmp/re.so: file too short
solar@...ia /tmp $ ls -l re.so
-rw-r--r-- 1 solar solar 0 Jun 5 01:22 re.so
(2) yeah that's pretty much 50% of the problem.
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Hosted by DataForce ISP -
Powered by Openwall GNU/*/Linux