develooper Front page | perl.perl5.porters | Postings from August 2016

Re: [perl #128800] base.pm broken in Perl 5.24.1 rc2

Thread Previous
From:
Zefram
Date:
August 2, 2016 19:29
Subject:
Re: [perl #128800] base.pm broken in Perl 5.24.1 rc2
Message ID:
20160802192901.GP24721@fysh.org
You have misunderstood the vulnerability.  "prove foo.pl" is vulnerable
only in the same way as "sh foo.sh": sure, in a world-writable directory
the requested file could be replaced by an attacker, but that's inherent
in what the user requested.  We do not regard that as a vulnerability in
prove or in perl.  A particular test script can be vulnerable, depending
on its module usage, but that's specific to the test script, not a general
problem with prove.  Likewise, while world-writable directories in @INC
are certainly a problem, they've generally got there by user request,
through PERL5LIB or -I.  That's an issue worth blogging about, but it's
not the security issue at work here.

The problem is specifically with the . that exists in @INC by default.
It's a problem because the user hasn't requested it.  The problem
is also specifically with optional module loads.  If a program loads
modules on a mandatory basis, then we expect that when it's installed
those modules will be installed, so the program's operation won't ever
reach the . in @INC.  The problem is with programs that load modules
optionally, and so might be installed without them, in which case the
. in @INC would routinely be used when the program runs.

In the absence of a global change to the initialisation of @INC, the
best solution is for the program at top level to remove the implicit
. from @INC.  Essentially every Perl program ought to do this.  We are
in fact making that change to Perl programs that we control.

The reason why we're also doing the much nastier @INC twiddling in modules
that perform optional module loading is to get sufficient coverage.
It's far too easy for Perl programs to slip through, never getting the
fix at top level.  This is especially true if the program doesn't know at
top level that there will be some optional module loading by some module
that it uses.  Most optional module loading is performed by modules,
so by applying patches there we can cover most vulnerable module loading
even in the presence of Perl programs whose authors aren't fully aware
of the issue.

I agree with you on the matter of documentation.  We do need to make the
compatibility issue clearer in perldelta and in the base.pm documentation.
We also need to make the issue with base.pm more discoverable than it
was in the RC, and you'll be pleased to hear that there has been a big
improvement in diagnostics since the RC.

-zefram

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About