[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Upcoming change to perl: current directory in @INC



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.

Recently, some particularly severe examples of this behaviour were
observed, and as a result perl upstream issued a set of patches
dealing with the worst parts, which related to optional module loading
behaviour. This was included as a part of the perl DSA in July.

The long term plan upstream is to remove '.' from @INC by default for
the next major release (5.26), planned for spring 2017. This is the only
way to remove this class of vulnerability completely. Given the Debian
release cadence, impending freeze, and queued perl 5.24 transition,
we would like to do the same in Debian ASAP[2].

The change will be made at first in a user-configurable way, by
uncommenting the line in /etc/perl/sitecustomize.pl which removes '.'
from @INC dynamically. This is almost identical to it not being in @INC
at all since sitecustomize.pl is run very early in the interpreter's
lifecycle. The change can be easily reverted by any administrator who
is affected by the change in the short term. Of course, this brings with 
t the same level of risk that exists now and is not recommended as a
long-term fix.

After the release of stretch, this change is likely to be a compile-time
default at which point it will no longer be user-configurable.

A round of QA has happened for build failures caused by this change
and bugs[3] filed for all affected packages. With a couple of
exceptions patches are available to fix the immediate build failures.

What's not so clear is the scope of breakage that will be seen at
runtime; but it seems obvious that there will be some. The fixes will
vary according to the exact situation, but will often include
sanity-checking whether it is safe for '.' to be in @INC for a given
program, and then readding it either in a BEGIN block, or possibly
by setting the transitional PERL_USE_UNSAFE_INC variable in the
environment of the perl interpreter (though we recommend avoiding this
where possible since it will only be supported for one release cycle.
As an example of where it's safe for '.' to be in @INC, is in package
build systems, where '.' is assumed to be the source tree or some
subdirectory of it and is hence implicitly trusted. (Changes were made
in debhelper and cdbs to run Makefile.PL and Build.PL with -I. in order
to fix a large class of build failures along these lines)

The change[4] is planned to be uploaded on Wednesday 31st August, and
accordingly, the FTBFS bugs have been upgraded to RC status today.

Please copy any bugs found as a result to perl@packages.debian.org
and if possible usertag them with user debian-perl@lists.debian.org,
tag perl-cwd-inc-removal. This will help us to track the impact of
the change, which will in turn help upstream, and also advise on
possible fixes if needed.

Thanks,
Dominic (for the Debian perl maintainers).

[1] <https://bugs.debian.org/588017>
[2] <https://lists.debian.org/debian-release/2016/07/msg00456.html>
[3] <https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-cwd-inc-removal;users=debian-perl@lists.debian.org>
[4] <https://anonscm.debian.org/cgit/perl/perl.git/commit/?id=dfbbbeb1cd8bc2731785f3bb9e29ab59f14ee9a4>

Attachment: signature.asc
Description: Digital signature


Reply to: