Re: Upcoming change to perl: current directory in @INC

[Raphael Hertzog]

On Thu, 08 Sep 2016, Russ Allbery wrote:
> Lars Wirzenius  writes:
> > Python doesn't put . in sys.path (the search path for imported
> > modules). It puts the absolute path where the script was found as the
> > first element. See https://docs.python.org/2/library/sys.html#sys.path
> > for details.
> 
> That's a little better but not a lot better.  It means that it's still
> unsafe to run any script out of a world-writeable directory such as /tmp,
> even if the sticky bit is set.

And we have cases of this: I just filed #837534: apt-listchanges: postinst
runs a Python script out of /tmp/.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: Upcoming change to perl: current directory in @INC

[Jakub Wilk]

* Lars Wirzenius , 2016-09-08, 14:04:
See https://docs.python.org/2/library/sys.html#sys.path for details. 
That page documents the cases where the empty string (effectively the 
same as .) are inserted into the beginning of sys.path, but they're not 
relevant for installed software: one is for when you run python and 
import on the REPL command line, the other is when you provide the 
script on the command line ("python -c 'foo bar'").


There's plenty of installed shell scripts that call "python -c 'foo 
bar'".


And there's even software that creates Python scripts in /tmp and then 
calls them: https://bugs.python.org/issue16202 *cough*cough*cough*


--
Jakub Wilk

Re: Upcoming change to perl: current directory in @INC

[Russ Allbery]

Vincent Lefevre  writes:
> On 2016-09-08 08:44:54 -0700, Russ Allbery wrote:

>> That's a little better but not a lot better.  It means that it's still
>> unsafe to run any script out of a world-writeable directory such as
>> /tmp, even if the sticky bit is set.

> Running things in /tmp or its subdirectories is prone to security
> bugs people do not care to fix.

And yet, sadly, people do it all the time.  :(

-- 
Russ Allbery (r...@debian.org)   

Re: Upcoming change to perl: current directory in @INC

[Vincent Lefevre]

On 2016-09-08 08:44:54 -0700, Russ Allbery wrote:
> That's a little better but not a lot better.  It means that it's still
> unsafe to run any script out of a world-writeable directory such as /tmp,
> even if the sticky bit is set.

Running things in /tmp or its subdirectories is prone to security
bugs people do not care to fix.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Upcoming change to perl: current directory in @INC

[Simon McVittie]

On Thu, 08 Sep 2016 at 08:44:54 -0700, Russ Allbery wrote:
> I don't see any inherent reason why that
> should have to be the case (other than, of course, that this Python
> behavior is long-standing and lots of software depends on it

I suspect that Python scripts relying on their own directory being
put on sys.path are going to be a lot more common than Perl scripts
relying on the current working directory being in @INC. The Perl
script author doesn't (usually) control the current working directory
at the time of invocation, whereas the Python script author usually
does control where the script gets installed relative to its required
library.

In particular, this is quite a common idiom, because it's one of the
few ways you can have private Python modules (and hence not have to
care about having a stable API, which isn't in-scope for every project)
without explicitly setting sys.path to a value hard-coded at install time:

Source tree:
~/src/myapp or whatever
  |- myapp/
  |  \- __init__.py (etc.)
  \- run (a #!/usr/bin/env python script including "import myapp")

Installed:
/usr/bin/myapp
  \- myapp -> /usr/share/myapp/run (symlink)

/usr/share/myapp
  |- myapp/
  |  \- __init__.py (etc.)
  \- run

When developing, you run "./run --args", and Python puts the equivalent
of $(pwd) on sys.path, and uses $(pwd)/myapp for "import myapp".

When installed, you run "myapp --args" and Python follows the symlink,
finds /usr/share/myapp/run, puts /usr/share/myapp on sys.path, and uses
/usr/share/myapp/myapp for "import myapp".

S

Re: Upcoming change to perl: current directory in @INC

[Russ Allbery]

Lars Wirzenius  writes:
> On Thu, Sep 08, 2016 at 11:55:26AM +0100, Dimitri John Ledkov wrote:

>> Other languages do that too. E.g. python, Doesn't python have the same
>> concerns then too?

> Python doesn't put . in sys.path (the search path for imported
> modules). It puts the absolute path where the script was found as the
> first element. See https://docs.python.org/2/library/sys.html#sys.path
> for details.

That's a little better but not a lot better.  It means that it's still
unsafe to run any script out of a world-writeable directory such as /tmp,
even if the sticky bit is set.  I don't see any inherent reason why that
should have to be the case (other than, of course, that this Python
behavior is long-standing and lots of software depends on it, but that's
probably true of Perl as well -- I already had to fix one place where I
was relying on this behavior and hadn't realized I was).

-- 
Russ Allbery (r...@debian.org)   

Re: Upcoming change to perl: current directory in @INC

[James McCoy]

On Thu, Sep 08, 2016 at 02:04:21PM +0300, Lars Wirzenius wrote:
> On Thu, Sep 08, 2016 at 11:55:26AM +0100, Dimitri John Ledkov wrote:
> > On 29 August 2016 at 14:39, Dominic Hargreaves  wrote:
> > > tl;dr: '.' is being removed from perl's @INC by default; some breakage
> > > in apps expected.
> > >
> > > For some years[1], it's been known that perl's habit of including '.'
> > > in its module load path, (@INC) is potentially dangerous, since it
> > > can allow untrusted code to be run under certain circumstances. However,
> > > for most of that time it wasn't taken that seriously, particularly as the
> > > fix is quite disruptive.
> > 
> > Other languages do that too. E.g. python, Doesn't python have the same
> > concerns then too?
> 
> Python doesn't put . in sys.path (the search path for imported
> modules). It puts the absolute path where the script was found as the
> first element.

Although, there were similar problem when embedding Python in other
programs.  See CVE-2008-5983[0] for the Python side of the issue.  There
were also various CVE's at the time for the programs that were doing the
embedding (like Vim[1], X-Chat[2], etc.).

[0]: https://security-tracker.debian.org/CVE-2008-5983
[1]: https://security-tracker.debian.org/CVE-2009-3916
[2]: https://security-tracker.debian.org/CVE-2009-3915

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: Upcoming change to perl: current directory in @INC

[Lars Wirzenius]

On Thu, Sep 08, 2016 at 11:55:26AM +0100, Dimitri John Ledkov wrote:
> On 29 August 2016 at 14:39, Dominic Hargreaves  wrote:
> > tl;dr: '.' is being removed from perl's @INC by default; some breakage
> > in apps expected.
> >
> > For some years[1], it's been known that perl's habit of including '.'
> > in its module load path, (@INC) is potentially dangerous, since it
> > can allow untrusted code to be run under certain circumstances. However,
> > for most of that time it wasn't taken that seriously, particularly as the
> > fix is quite disruptive.
> 
> Other languages do that too. E.g. python, Doesn't python have the same
> concerns then too?

Python doesn't put . in sys.path (the search path for imported
modules). It puts the absolute path where the script was found as the
first element. See https://docs.python.org/2/library/sys.html#sys.path
for details. That page documents the cases where the empty string
(effectively the same as .) are inserted into the beginning of
sys.path, but they're not relevant for installed software: one is for
when you run python and import on the REPL command line, the other is
when you provide the script on the command line ("python -c 'foo
bar'").

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Upcoming change to perl: current directory in @INC

[Dimitri John Ledkov]

Hello,

On 29 August 2016 at 14:39, Dominic Hargreaves  wrote:
> tl;dr: '.' is being removed from perl's @INC by default; some breakage
> in apps expected.
>
> For some years[1], it's been known that perl's habit of including '.'
> in its module load path, (@INC) is potentially dangerous, since it
> can allow untrusted code to be run under certain circumstances. However,
> for most of that time it wasn't taken that seriously, particularly as the
> fix is quite disruptive.

Other languages do that too. E.g. python, Doesn't python have the same
concerns then too?

-- 
Regards,

Dimitri.

Re: Upcoming change to perl: current directory in @INC

[Dominic Hargreaves]

On Thu, Sep 08, 2016 at 11:19:47AM +0100, Ian Jackson wrote:
> Dominic Hargreaves writes ("Upcoming change to perl: current directory in 
> @INC"):
> > tl;dr: '.' is being removed from perl's @INC by default; some breakage
> > in apps expected.
> 
> I seem to have missed this.  So, belatedly:
> 
> Hooray!
> 
> Thank you for taking care of our users' security.  I'm pleased to see
> Debian getting this change early.  Please carry on.

Thanks :)

> And: is there a way I can make this change in an installation of
> jessie or earlier ?  That would be useful for various testing
> purposes, and also might be appropriate in production systems where
> security is importand and breakage has a limited impact and can be
> fixed easily.

Yes, very easily - just uncomment the last line in
/etc/perl/sitecustomize.pl, on any up-to-date jessie or wheezy system.

Cheers,
Dominic.

Re: Upcoming change to perl: current directory in @INC

[Ian Jackson]

Ian Jackson writes ("Re: Upcoming change to perl: current directory in @INC"):
> And: is there a way I can make this change in an installation of
> jessie or earlier ?  That would be useful for various testing
> purposes, and also might be appropriate in production systems where
> security is importand and breakage has a limited impact and can be
> fixed easily.

I am an idiot who didn't read your message carefully enough.  I see
that the sitecustomize.pl change is available in jessie-security too.

Thanks!

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Upcoming change to perl: current directory in @INC

[Ian Jackson]

Dominic Hargreaves writes ("Upcoming change to perl: current directory in 
@INC"):
> tl;dr: '.' is being removed from perl's @INC by default; some breakage
> in apps expected.

I seem to have missed this.  So, belatedly:

Hooray!

Thank you for taking care of our users' security.  I'm pleased to see
Debian getting this change early.  Please carry on.

And: is there a way I can make this change in an installation of
jessie or earlier ?  That would be useful for various testing
purposes, and also might be appropriate in production systems where
security is importand and breakage has a limited impact and can be
fixed easily.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.